Harsha Smith wrote:
* Using interface as a type. What is the whole
point of this, why is this legal? Does it
make any sense?*/
Haven't you read the chapters "Inheritance" and "Polymorphism" yet?
yes, I have read them, but I don't know understand the purpose of using interface as a reference type. objects created using interface type can't access methods of the class that implements it. I was thinking objects of interface type should have additional methods instead, but it is the other way around.
Randy Smith wrote:
Campbell Ritchie wrote:I would prefer to see the method called launchRocket().
when both Car and FighterPlane implement Weapons, all Cars and FighterPlanes can launch rockets, why do we need to use Weapon as a type?
Try rewriting that code without using Weapon as a type.
A good example is if we take a Person that implements the interfaces HardWorker and GreatLover.
As your boss, I do care about the methods that you implements according to the HardWorker interface. But I don't really care about your other implementing interfaces.
As your partner, I don't like that your boss is calling the methods in the HardWorker interface since that takes away the possibility for me to call the GreatLover-methods. And some stupid programmer has put a synchronization on the implementing methods.
So, depending on who is using the implementing type, they want to know that you can do what your interface/specification promises.
Randy Smith wrote:Greetings, I would appreciate if someone could explain the purpose of using interface as a type...
I'll leave the "why is it legal" to someone else, because almost always the answer to questions like that is "because the Java designers thought it was a good idea".
And it is. Here's a real-life example:I've just written a method that works with 4 different classes (and probably many more), simply because instead of defining its parameter as a class, I defined it as an interface; and because I did that, it'll work with any class that implements List (or, in the above case, List<String>).
And when you define a field (eg, 'al' above), if you define it using the interface type, you can change your mind later. Assuming that all my methods are written to take Lists, rather than ArrayLists, I can change the above definition to:
List<String> al = new AttributeList<String>();
and everything will continue to work just fine.
Team B says "We will create a widget object that implements the fubar interface.".
Team A can do one of two things. They can code to the specific type of object (widget) that actually gets created, or they can code to the interface given (fubar).
Let's say they code to the specific type of widget. a year later, just two days before go-live, Team B says "We need to change the object we are giving you. It won't be a widget, but a dohicky, which also implements the fubar interface.".
Team A is screwed. They need to go through every line of code and change it to use the dohicky type.
If only they had used the fubar interface, they WOULDN'T HAVE TO TOUCH A LINE of code - because any dohicky can be assigned to a fubar interface type.