Struggling with the concept of Interface and Abstract

[ascotta]

I am really struggling with this Interface malarky.

What is the point of them ?

Why would I create a list of methods that I am promising to implement, when I am going to put them in the program anyway. I cannot fathom this one out. I really need a real world and I mean real world example, to get my head round it. There is obviously a good reason, it's just I am too thick to geddit.

Also any pointers where I can read some stuff about abstract things.

I am an ex-Cobol programmer so very procedural in mentality.
Have understood basic class stuff but these are getting to me.


Cheers
Scott

 

[paulb567]

http://java.sun.com/docs/books/tutorial/java/index.html

Take a look at

Classes and Inheritance
Interfaces and Packages

Should get you started.

 

[sedj]

Its got a lot to do with specifications.

For example, Sun and the Java Community Process decide that there should be a new technolgy, lets call it "JCQ". Now, the JCP and Sun spec it out, but they want vendors such as JBoss or Orcale to actually write their own implementations of, tailored to their own J2EE server or whatever. But he programmer still wants a set of "known classes" to work with. So Sun writes all the interfaces (and or abstract classes) to define the JCQ technolgy. Now when the vendor writes their implementation, they "implement className" which means the programmer can use a well-diefined standatrd package, but is really using the vendor's specific classes.

 

[ascotta]

OK I got the abstract one, but I still do not see the point of interfaces.

If I want to write a method then I write a method. Why should I create a file that basically provides a list of methods and the parameters to those methods. I still have to write the method ?

Baffled.

Cheers
Scott

 

[sedj]

Take the interface java.sql.Connection .

For each databse vendor, the way in which SQL statements are executed against a database is vendor specific. But as a programmer, you don;t want to have to chnage the code you write every time you use a different database. So Sun provides an interface such as java.sql.Connection to lay out the ground methods that vendors should implement. Then when you call DriverManager.getConnection it returns somehting like "com.mysql.jdbc.Connection" (for MYSQL) or "oracle.jdbc.OracleConnection" (for oracle) - but because these classes implement java.sql.Connection - you can use this base interface - because it defines the methods in the vendor specific classes.

 

[paulb567]

Think about the following example.

You create an interface called Shape..

public interface Shape {

  public int getArea();

}

You could then create two different classes implementing Shape called Square and Circle

class Square implements Shape {

  private int width;
  private int height;

  public Square(int w, int h) {
    width = w;
    height = h;
  }

  public int getArea() {
    return width * height;
  }
}

class Circle implements Shape {

  private int radius

  public Circle(int r) {
    radius = r;
  }

  public int getArea() {
    return Math.PI * r * r;
  }
}

Then say you were to write some code that processed a list of different shapes

public static void main(String[] args) {

 Vector shapes = new Vector();
 shapes.add(new Sqaure(4,4));
 shapes.add(new Circle(12));
 ..etc
 ..etc

 for (Iterator it = shapes.iterator(), it.hasNext(), ) {
  Shape currentShape = (Shape)it.next();
  System.out.println("Area = "+currentShape.getArea());
 }
}

Basically, it doesn't matter if currentShape is a square or circle because you know Shape has a method called getArea.

Sorry, thats probably a really lame way of trying to explain it. It becomes very useful in more complex applications. It allows you to handle situations where you might not know what particlular class an object is, but if you know it will implements a certain interface then you know you can call any of the interfaces methods on the object regardless of its class.

 

[paulb567]

Sorry, sedj's explanation is much better than mine.

 

[ascotta]

Hmmmmmmmmmmmm

I think I will read the sql interfaces and see what its all about.

I still don't see why I would ever have to write an interface. Although I see what is happening. I cannot see why I would go to all the trouble of repeat typing.

But I am a little wiser thank you.


Cheers
Scott

 

[sedj]

Well, you probably will never have to write an interface yourself - I've been writing java for 2.5 years and have written about 2 - you only need to write them if you can envisage different implementations being required, but having one main object to call (such as database code).

 

[ascotta]

Aha, then it does make sense and I am not totally thick then.

thank you

Cheers
Scott

 

[AS2Expert]

Scott, I had struggled with this issue as well. My background was in ForTran and C - very procedural. When I went to C++, I was able to understand the concept of objects, but had difficulty understanding inheritance and definitely couldn't understand why one would use interfaces. I read books and tried examples but just didn't get it.

In my current position, I develop Java code to send secure documents over the internet using http (it's called AS2 - hence my handle: AS2Expert).

About a month ago, I started working on a project to send these same secure documents over the internet, but now using ftp. (This is known as AS3.) I was now able to use the concept of interfaces and inheritance in a real-world example. I already had all this code that I had written to send data over http and didn't want to reinvent the wheel for all the common code that I had already written.

I moved all the common code that AS2 & AS3 would both use into parent classes (some abstract, some not) and extended those classes and overrided the methods that were slightly different. This is INHERITANCE. It saved me a lot of work.

Now I had some support classes were instantiated that by AS2 classes and were casting my AS2 class to use some of the methods from that class, i.e.,

(AS2Class)myMethod;

I wanted to also be able to cast to my AS3 classes when my AS3 classes instantiated them so I passed in a reference to the class I was instantiating (call it myclass) and I thought I'd have to do alot of this (which is really a pain):

if (myclass instanceof AS2Class)
(AS2Class)myMethod;
else if (myclass instanceof AS3Class)
(AS3Class)myMethod;

Both classes have the same method name but do different things in those methods. To make life a lot easier for myself, I created an interface, let's call it GenericClass, that defines all the common methods used by these support classes (like myMethod described above).

Both AS2Class and AS3Class now implement the interface GenericClass. Now everywhere where I used to reference AS2Class, I now reference GenericClass and so I don't have to do any if/else checks and all that casting, and I don't have to pass in a reference to myclass. So instead,

if (myclass instanceof AS2Class)
(AS2Class)myMethod;
else if (myclass instanceof AS3Class)
(AS3Class)myMethod;

becomes
(GenericClass)myMethod

At runtime, Java substitutes the correct class (either AS2Class or AS3Class) in all the places in the support classes where GenericClass was declared. It definitely made my life easier.

Hope this clears it up for you.

 

[stefanwagner]

my two cents:

The interface is a kind of a contract.
You define what a class has to provide at minimum to fullfill the contract/ interface.

Now a third party might use the interface, and another third party might implement new classes.

If the shape-example had some more methods:

move (int x, int y);
colorize (Color c);
flip (Axis a);
rotate (Point center, int degree);
zoom (int factor);
paint (Graphics g);
// ...

One party could create an Application, to make a UserInterface to manage Shapes, by adding them, removing them, combining, ...
The second party could implement new Shapes, like Triangle, Oval, Pentagon, ...

Both parties only need to know the Interface.
You can add specific Shapes later to the Application, without recompiling it. The Application can call the 'move'-Method of an Object, which wasn't defined when the Application was compiled.

Eclipse is a big Tool, combined from Plugins, which uses the concept of Interfaces extensively.

seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung