It is that simple. But of course that does not give you the true feeling for the POWER of interfaces.
Lets say that I want to create a class or a method that takes a parameter. Only I don't know WHAT exactly the thing that is going to be passed is going to BE. You can't put a variable in the method definition
public void myMethod(IDontKnowWhat x){ //do stuff};
However you do know that in the do stuff area that you need the thing that is passed to be able to have specific behaviors. For instance, let's say that whatever is passed has to be able to execute a play() method.
Well if you have an interface that includes a play() method (let's call it BabyStuff) then you know that you will be able to handle any class that implements BabyStuff. Now you can code your method using the interface name as the "variable parameter" and be safe.
public void myMethod(BabyStuff x){ //do stuff that includes play()};
The same theory holds true for Fields (variables). You can create a variable that can hold a variety of objects by
BabyStuff b = (an instance of any class that implements BabyStuff);
Now you can use the "b" variable freely, even though you do not know what EXACT class that the object it refers to is. Of course while it is referenced through the "b" variable you can only expect it to do BabyStuff things even though as an instance of some other class it can probably do much more, but it is limited by the type of the variable that is holding it. On the other hand you have gained the ability to be able to hold a variety of different class objects this way, and be able to manipulate them in a consistant manner.
It is for these reasons that there is a basic principle of Object Oriented design that says:
Program to an interface, not an implementation
("Design Patterns" - Gamma, Helm, Johnson & Vlissides)
[This message has been edited by Cindy Glass (edited June 21, 2001).]
