Greetings, I would appreciate if someone could explain the purpose of using interface as a type. And why is it legal? I find it quite confusing, perhaps there is a better example to use interface as a type?
* 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.
An interface is a specification (or contract) that tells the caller that the implementing type has the capability to do something.
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.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
You should also remember that large projects are developed by teams. For example, team A develops the client, and team B develops the back-end server.
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.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop