Different appliances may implement what "on" and "off" should do as they deem appropriate (e.g., "on" for a lamp is to show light, "off" for an air conditioner is to stop guzzling power, etc.).
The fact that an electical appliance "implements" the (electrical) "switch" interface or the "outlet" interface is important for me to know. It could be battery driven and have its own "on" and "off" equivalents, but that may not be what I am interested in.
I can write this:
FredInterface myRefInterface = callToYourCode();
Now, it doesn't matter if i get back a SankarObject, an AnandObject, or a CamiloObject. as long at each of those objects implements my interface, ANY object can be returned.
But Anand, the interface "switch" has empty methods "on" and "off". The electrical appliance who implements "switch" has definitions of "how to turn on lights" and "how to turn off" right.
Still I wasn't clear about the usage of interfaces.
Can you please explain a bit more.
Welcome to JavaRanch
The Power of interfaces is the ability to achieve Polymorphism.
Especially at runtime in terms of having a common methodology wherein you can pass an object of Interface (which cannot be directly instantiated of course but can hold the objects of classes which implement the interface) to a method which can act accordingly based on the *actual* object being passed. This is something like as Fred said above.
Generally, An interface provides a contact or an agreement saying that whoever is going to join the common forum (wherein they have to implement the interface) should have to have an implementation of all the methods but everyone is allowed to have their own version. Means, agreeing for the general or common rules. Its something like agreeing the rules of an apartment when you are in room, college when you are in classroom etc.
That means, the implementation is not restricted to any boundaries. Its totally upto the class which is implementing the interface. But what an interface all does is insisting the implementing class to keep a definition of its methods, so that if you have an Interface object you can deal with any of the objects of its implementing classes.
Assume a scenario where in the implementation of methods are NOT insisted and some classes do implement and some others don't. At runtime, you just get an object in the form of an interface, after getting it and typecasting it to the appropriate object, you will definitely expect it to have the implementation of the method of interface. What if this object belongs to the class which does not implement?
Getting back to the switch "on" and "off" example given by Anand, in case of having an interface whatever the electrical appliance you get, you are rest assured that it SHOULD have the implementation of the method. Meaning, when you switch "on" the device (in programming terms, when you invoke a particular method, here its "on"), it will NOT blink as if it does not know how to react. It would blink if its not programmed for that action.
Had it been a case of having a class instead of an interface (as per your original question), the above said situation may occur as some electrical devices may leave the implementation undefined.
Does that help you?
[ August 17, 2007: Message edited by: Raghavan Muthu ]
Originally posted by sankar narayanan:
Interfaces only has method signatures. so anyway all the implementing classes should implement those methods. Then what is the use of interfaces? Even if it is not there, the class can declare and define the method right???
Pls clear my doubt.
Thanks in advance,
One of the uses of interfaces is as a method input parameter (instead of the method specifying a specific class type for the parameter):
The advantage of the method taking an interface is that this method can now be used by any class that implements the interface SomeInterface, rather than any class that is a SomeClass or derives from SomeClass. So by using an interface you expand the amount of classes that can use your method.
If classes implemented the interface methods without declaring the interface, as you suggest, they all have to be derived from a common base class that also implements it, otherwise you end up having to overload your methods:
[ August 17, 2007: Message edited by: Red Smith ]