This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Why do you guys think that interfaces came into Picture when Abstract Classes can do that Job. Even much more then what Interfaces can offer I mean Interfaces can only contain Method Declaration where as Abstract Classes can have both the Declaration and Defination of some methods.
Also Please don't say that Interfaces we can have Multiple inheretence whereas in Abstract Classes this is not Possible. As I allredy know this and I answered the same. But I think there is one more reason which is still now clear to me. That is what I think my Interviewer was Looking for.
Well, in my opinion, the interfaces are just a right way how to do certain things. Look at it logically. You have for instance your data structure representing a family tree and you want to display it in a JTree. Now, the logic of the data structures is NOT that your tree should be a descendant of, I don't know, AbstractTableModel, but you just want to have this JTree view through which you will look at the family tree. And the JTree object will just look at your data structure through the TreeModel interface.
Honestly I think that this multiple inheritance is nonsense. I have never come to a situation where it would be necessary, or even useful. If you think about the example above, I guess in C++ you would implement it using multiple inheritance. But that is not what it should be because it does not really add any new features. It's just a "sideway view".
I just hope not to start too big a flamewar by this ;-)
Get a better web browser:<br /><a href="http://www.mozilla.org/products/firefox/switch.html" target="_blank" rel="nofollow">http://www.mozilla.org/products/firefox/switch.html</a>
I think the use of Interfaces and Abstract classes depends on the application design. Consider the following scenario:
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.
Originally posted by Rahul Juneja: Also Please don't say that Interfaces we can have Multiple inheretence whereas in Abstract Classes this is not Possible. As I allredy know this and I answered the same. But I think there is one more reason which is still now clear to me.
As far as I can tell, giving us MI for interfaces is exactly the only one reason for the existance of Interfaces in Java. If we had MI for classes, purely abstract classes could do the job.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Honestly I think that this multiple inheritance is nonsense.
What if you have data that you want to display in both a JTree and a JTable? It seems appropriate to have a data class that implements both a TreeModel and a TableModel - seems like an ok design choice to me.
Interfaces and "pure" abstract classes are exactly the same only if you look at a software system as a snapshot, a thing frozen in time.
But that's not really what software is, and it's not what OO is about. If it were, there'd be no need for OO, we could have stayed with procedural programming and been fine.
OO provides a framework to allow software systems to *evolve* intelligently. This is absolutely fundamental to OO. If you have the tendency to think, "Oh, well, sure, if things *change*, but let's assume that it won't change..." then you've completely misunderstood the problem that OO addresses in software. OO addresses change. OO exists to deal with change.
So, if you discard your procedural programming view of software, you'll begin to see a growing distance between interfaces and abstract classes. In the context of an evolving system, there are certain things that abstract classes can do that interfaces can't. Specifically, they can have method implementations added. Interfaces do not support this. This makes all the difference.
When a class implements an interface, that class is saying: I do x, y, and z. When a class extends an abstract class, even if it's a pure abstract class, the statement is different: I do x, y, and z *in the same way as my superclass*, unless I override the method myself. The point is that a subclass and an abstract class don't just share capability and behavior...they share implementation.
What if they don't? I did say it was a "pure" abstract class I'm talking about, right? Ahhh...but you're thinking from a static point of view again. The proper way to look at an OO system is not, how is it designed right now, but rather, what are the degrees of freedom for the evolution? If you extend an abstract class, you're inviting someone in a later version to start implementing methods on that abstract class and your subclass will inherit those. If that's exactly what you want, then use an abstract class. If it absolutely isn't, then state that by implementing an interface instead.