wood burning stoves 2.0*
The moose likes Java in General and the fly likes Why Interfaces Came into Picture ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Why Interfaces Came into Picture ?" Watch "Why Interfaces Came into Picture ?" New topic
Author

Why Interfaces Came into Picture ?

Rahul Juneja
Ranch Hand

Joined: Aug 03, 2002
Posts: 425
All,

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.

If anybody can throw some light on this.

Thanks,
Rahul Juneja
rahulj2k3@yahoo.com


Rahul Juneja
ThoughtClicks - http://techlabs.thoughtclicks.com
Petr Blahos
Ranch Hand

Joined: Apr 28, 2004
Posts: 131
Hi Rahul,

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 ;-)

Petr


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>
Vicky Jain
Ranch Hand

Joined: Aug 02, 2003
Posts: 52
Hi Brother,

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.

You may find out more here:
http://java.sun.com/developer/JDCTechTips/2001/tt1106.html
http://mindprod.com/jgloss/interfacevsabstract.html

ThanX


SCJP1.4(96%)<br />A drop of ink can make millions think.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
Originally posted by Ilja Preuss:


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.


Correct. Therefore the reason for interfaces is to prevent the need for C++ style multiple inheritance.

The fact that they more correctly describe the responsibilities in a system than do pure abstract classes (in many cases) is a related reason.


42
Rovas Kram
Ranch Hand

Joined: Aug 08, 2003
Posts: 135
Hi Petr,

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.
sever oon
Ranch Hand

Joined: Feb 08, 2004
Posts: 268
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.

sev
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why Interfaces Came into Picture ?