Interface

[Andreex]

OK.... I am learning interfaces. But... I still havent found what they are for. I know you declare and interface like this:

public abstract interface inter

{
int a=1;
public void hola1();

}

Now... the methods cant contain code. WHY? Then why would I want to implement an interface if I am only implementing names and not code? If I have to code the method in my class anyway... why would I want to implement the interface?

I know there something I am missing... can somebody please explain???

[Dillinger4]

Instead of giving you a long winded answer ill give you a little chunk and work from there. From what i know Java implements what is called linear implementation inheritance. Meaning that a class can have only one parent or superclass.
Because this relationship is linear, it rules out multiple implementation inheritance Languages such as C++ which support multiple implementation inheritance are very complex and problems often arise.

Interfaces were introduce in Java to support multiple interface inheritance

[billrogers]

Here is a good explanation that should help ya out that will be long winded, yup multiple inheritance is key with interfaces....

Class vs. interface
Some say you should define all classes in terms of interfaces, but I think recommendation seems a bit extreme. I use interfaces when I see that something in my design will change frequently.

For example, the Strategy pattern lets you swap new algorithms and processes into your program without altering the objects that use them. A media player might know how to play CDs, MP3s, and wav files. Of course, you don't want to hardcode those playback algorithms into the player; that will make it difficult to add a new format like AVI. Furthermore, your code will be littered with useless case statements. And to add insult to injury, you will need to update those case statements each time you add a new algorithm. All in all, this is not a very object-oriented way to program.

With the Strategy pattern, you can simply encapsulate the algorithm behind an object. If you do that, you can provide new media plug-ins at any time. Let's call the plug-in class MediaStrategy. That object would have one method: playStream(Stream s). So to add a new algorithm, we simply extend our algorithm class. Now, when the program encounters the new media type, it simply delegates the playing of the stream to our media strategy. Of course, you'll need some plumbing to properly instantiate the algorithm strategies you will need.

This is an excellent place to use an interface. We've used the Strategy pattern, which clearly indicates a place in the design that will change. Thus, you should define the strategy as an interface. You should generally favor interfaces over inheritance when you want an object to have a certain type; in this case, MediaStrategy. Relying on inheritance for type identity is dangerous; it locks you into a particular inheritance hierarchy. Java doesn't allow multiple inheritance, so you can't extend something that gives you a useful implementation or more type identity.

Interface vs. abstract class
Choosing interfaces and abstract classes is not an either/or proposition. If you need to change your design, make it an interface. However, you may have abstract classes that provide some default behavior. Abstract classes are excellent candidates inside of application frameworks.

Abstract classes let you define some behaviors; they force your subclasses to provide others. For example, if you have an application framework, an abstract class may provide default services such as event and message handling. Those services allow your application to plug in to your application framework. However, there is some application-specific functionality that only your application can perform. Such functionality might include startup and shutdown tasks, which are often application-dependent. So instead of trying to define that behavior itself, the abstract base class can declare abstract shutdown and startup methods. The base class knows that it needs those methods, but an abstract class lets your class admit that it doesn't know how to perform those actions; it only knows that it must initiate the actions. When it is time to start up, the abstract class can call the startup method. When the base class calls this method, Java calls the method defined by the child class.

Many developers forget that a class that defines an abstract method can call that method as well. Abstract classes are an excellent way to create planned inheritance hierarchies. They're also a good choice for nonleaf classes in class hierarchies.

[Dillinger4]

interfaces come in handy when you want to define constants or method prototypes. An interface is always abstract by nature so you dont have to declare an interface with the abstract keyword.

If you define any constants within your interface they are always declared public static final regardless of wether these modifers are specified.

[Andreex]

Thanks billrogers and Dilenger4. That was a good explanation.

So... of what I could understand.... interfaces... are only for method prototypes???? How come when I implemet... lets say... KeyListener... I besides the methods protoypes... I get something "extra". You know what I mean... with the keylistener I actually can subclass the keyboard... so... there has to be something more than methods name in keylistener.... right???

[Dillinger4]

I think what bill is talking about when it comes to Interface vs. abstract classes is that if a class implements an interface then the class must provide implementation for all of the method prototypes that are contained within the interface. If the class that implements this interface fails to do so then it becomes abstract. So it seems that the implementation is forced.

If a class extends an abstract class then all it has to do if it doesnt want to be abstract is provide implementation for all of the abstract methods that are contained within the abstract class. It is not obligated to provide implementation for any of the non-abstract methods. So implementation is not forced.

[billrogers]

you got it. Dont worry this crap is confusing as hell the first time ya go through it. Once you go through it actually code it and keep reading examples it will make sense. Once you grasp these ideas you will have a powerful tool at your fingertips.

Although i have to admit, it takes a good sized project for these areas to really be super beneficial.

[Dillinger4]

Hey bill how do you feel about inheritance vs Aggregation?

[billrogers]

Hmm, lets see Inheritance versus Aggregation...

Lets look at the two

Inheritance is an is-a relationship. It may be veiwed by making a public declaration that objects of a sub-class obey the semantics of their super-class. So in essence the sub-class is adding to, or making an instance of the super-class specialized. It is often implemented to reuse code to the fullest extent. It can be used without the use of polymorphism but it does not make it the most useful thing, since polymorphism and dynamic binding go together.

Aggregation is a part relationship. There are two ways for aggregation to really work containment either by value or reference. This can get a little more tricky so lets take a shot at it. With either containment option (value or ref.) the contained object doesn't exist independently. But with reference the lifetimes of the two objects are not tightly interwined as is the case with by value. With by value the contained object is toasted when the container is toasted and with by value they can be created and toasted independently of each other and instance have the ability to be contained in many different instances of containers. Cyclic containment is also an issue, it is possible with by ref. not so with by value. Java is great for by ref. thanks to the JVM garbage collecter.

When you think of it, think of something like a real world example.
For example, windows and unix are kinds of operating systems. (this is an example of inheritance), where as aggregation comes in with the parts. The kernal is part of both kinds of operating systems.

I personally have not used aggregatiion much, I know C++ can switch between the two with not losing any semantics, where as java, if I remember right can not, has trouble with by value.

hope this helps ya out, I must hit the hay, I am beat.
Bill

[Dillinger4]

Hummmm interesting. It's late so my thought process is a bit fuzy. Ill have to read this over tommorow. Thanks

[billrogers]

ya, you should have tried writing that last night at 12.

[Dillinger4]

Posted by Andreex
So... of what I could understand.... interfaces... are only for method prototypes???? How come when I implemet... lets say... KeyListener... I besides the methods protoypes... I get something "extra". You know what I mean... with the keylistener I actually can subclass the keyboard... so... there has to be something more than methods name in keylistener.... right???

I know what you are saying since interfaces
only contain method signatures not actual
code then where does the functionality come
from? Ive been programming in Java for a while
and i have yet to use interfaces. With inheritance
at least i get code reuse and if there is no
apparent "is a" relationship then i just use
aggregation. For instance when you define a
class to extend the KeyAdapter class the you
can overide any method you like. This is because
the KeyAdapter class already impelements
an interface. If you implment the KeyListener
interface then you must provide implementation
for every method declared within the interface
or your class will become abstract but if the code
is not contained in the interface then where is it?
Don't worry im still trying to figure it out too.

[billrogers]

LOL, I wrote some the above stuff and it still can confuse the hell out of me sometimes...