aspose file tools*
The moose likes Java in General and the fly likes Difference from design perspective Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Difference from design perspective" Watch "Difference from design perspective" New topic
Author

Difference from design perspective

Naseem Khan
Ranch Hand

Joined: Apr 25, 2005
Posts: 809
Hi,
Can nybody tell me the difference between abstract class and interface from design point of view. This questions waz asked 2 me in an interview.

Tx.

Naseem Khan


Asking Smart Questions FAQ - How To Put Your Code In Code Tags
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Would the question make sense to you without the "from a design point of view" part? Give us your understanding of interface and abstract class and see how different they seem to you.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Naseem Khan
Ranch Hand

Joined: Apr 25, 2005
Posts: 809
My question waz when to use interfaces and when to use abstract classes. I hav seen on some websites that when design is changing frequently, then go for interfaces. But on the other hand, performances issues come with interfaces than abstract classes.
So how to choose between the two.

Tx.

Naseem Khan
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Originally posted by Naseem Khan:
My question waz when to use interfaces and when to use abstract classes. I hav seen on some websites that when design is changing frequently, then go for interfaces. But on the other hand, performances issues come with interfaces than abstract classes.
So how to choose between the two.

Tx.

Naseem Khan


The correct answer for the purposes of your interview would have been, "use an interface when you are at an abstraction level (in an inheritance hierarchy) where no (0%) implementation details are known; use an abstract class when partial (between 0% and 100% exclusively) implementation details are known; and use a concrete class when all (100%) implementation details are known". That is to say, your primary agenda when attending that interview was to provide the answer that the interviewer wants to hear; not what you think is correct.

Also note that anyone who suggests that there is a performance penalty for using interfaces needs a walloping. The call to a invokevirtual is neglible (and sometimes, nil), and in any case, the same 'penalty' will be applied to both interfaces and abstract classes. Given the lack of understanding of performance (which unfortunately, is incredibly common), they probably don't perform well in other areas either

The concept of 'abstract classes' is horribly flawed; avoid abstract classes altogether. In fact, avoid the abstract keyword altogether. Other keywords to always avoid: protected, switch, case. http://www.jtiger.org/articles/why-extends-is-not-evil.html
And remember, always think for yourself and have no fear of questioning orthodox beliefs, no matter what the cost. Time to run from stones being pelted at me
[ September 04, 2005: Message edited by: Tony Morris ]

Tony Morris
Java Q&A (FAQ, Trivia)
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
>> My question waz when to use interfaces and when to use abstract class.

Clearly that was not your question. I know what the question was but wonder what the question is now. Given this is the advanced forum we should assume the distinction between the two is something you already know. So I'm going to take the most recent of the set of questions you asked literally: when to use which.

I would have answered as follows. The abstract class provides a common base where the base itself should not be instantiated. Instantiating a Cherry or Plumb is reasonable but instantiating a Fruit may not be. Otherwise use the same criteria you would use for a base class.

An interface must be used when multiple inheritence is required. It has the added benefit of eliminating depencencies on the base class implementation, at the cost of providing the implementation yourself.
[ September 05, 2005: Message edited by: Rick O'Shay ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Tony Morris:
The concept of 'abstract classes' is horribly flawed; avoid abstract classes altogether. In fact, avoid the abstract keyword altogether. Other keywords to always avoid: protected, switch, case. http://www.jtiger.org/articles/why-extends-is-not-evil.html
And remember, always think for yourself and have no fear of questioning orthodox beliefs, no matter what the cost.


I'd add: always think and experiment for yourself, and have no fear of questioning any beliefs, wether orthodox or not.

Personally, I think that the keywords Tony "demonizes" can certainly be misused, but if used wisely actually can provide value.


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
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
I don't "demonize" anything, since to do so would violate the very principles that I am attempting to portray. All theories have an axiom, such that an ultimate truth can never be arrived at. Galileo makes this clear for the Scientific Method (which we are all implicitly using, even if inadvertant - we typically take it for granted).

A non-final class is an implicit software requirement defect. There is no questioning it, at least, not with any reasoning that I have seen. Perhaps we'll try the Marxist approach next?
Michael Ernest
High Plains Drifter
Sheriff

Joined: Oct 25, 2000
Posts: 7292

I like Joshua Bloch's advice on this point: Prefer interfaces to abstract classes. Here's a paragraph from Effective Java that makes a case for abstract classes:

Using abstract classes to define types that permit multiple implementations has one great advantage over using interfaces: It is far easier to evolve an abstract class than it is to evolve an interface. If, in a subsequent release, you want to add a new method to an abstract class, you can always add a concrete method containing a reasonable default implementation. All existing implementations of the abstract class will then provide the new method. This does not work for interfaces.


Make visible what, without you, might perhaps never have been seen.
- Robert Bresson
Rick O'Shay
Ranch Hand

Joined: Sep 19, 2004
Posts: 531
>> I don't "demonize" anything

Yes, in fact you do but what is particularly troubling is that you try to use gross generalities to back up your claims. You need to get a compass, set out your objective and expand on it. Going off on wild tangents and being preachy aren't helping to sell your position. There's a very condescending quality to your opinions. I think it's because you restate the obvious as if it was some sort of discovery. As an exercise, try to make a concrete statement of fact with a succinct example that focuses on the topic.
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
On the contrary, wanting to "add" a method to an interface implies that the interface was not written correctly in the first place. An interface should contain only methods that are symbiotic at a particular point in time. It's far, far "easier" (i.e. does not implicitly violate encapsulation or software requirements) to subtype the interface and write the appropriate implementation that is another level of abstraction lower such that symbiotism of its operations exists at that level.

That is to say, you can always achieve symbiotism without foreseeing the future (unlike abstract classes/cocnrete inheritance), since it's easily defined for a given point in time. If, over time, another definition of that symbiotism comes into existence, inheritance solves it simply with type safety (since SubInterface is always an instance of SuperInterface).

A perfect practical example is Object equals/hashCode. These methods break another principle of "all public methods on an interface", so let's suppose this rule wasn't broken:

This interface now breaks the rule of symbiotism. That is, does the "equals" operation exist alongside the "hashCode" operation, always or not at all? Initial intuition may suggest so (another example of how things appear versus how things are). Suppose the two operations could exist independantly in some contexts, but symbiotically in others:


An example of where symbiotism does and doesn't exist all at once is that a HashMap will (should) always have keys of type "EqualsHashCode" while its values would always have keys of type "HashCode", therefore the "hashCode" operation clearly is not symbiotic with the "equals" operation, and this is only a trivial example. There are hundreds more.

I often wonder what we would have today if only Bloch took those few more required steps in his analysis of design principles, particularly in a Java context.

<edit>
- Added code tags
- The forum didn't like my big long comment
</edit>

[ September 06, 2005: Message edited by: Tony Morris ]
[ September 06, 2005: Message edited by: Tony Morris ]
Michael Ernest
High Plains Drifter
Sheriff

Joined: Oct 25, 2000
Posts: 7292

Originally posted by Tony Morris:
On the contrary, wanting to "add" a method to an interface implies that the interface was not written correctly in the first place. An interface should contain only methods that are symbiotic at a particular point in time. It's far, far "easier" (i.e. does not implicitly violate encapsulation or software requirements) to subtype the interface and write the appropriate implementation that is another level of abstraction lower such that symbiotism of its operations exists at that level.

Bloch's point is to add a method to an abstract class rather than an interface. And, if something wasn't "correctly" written, there you have it. You could criticize that fact or you could do what's need to get on to the next release of software.

Or we could follow your program, but I don't understand it. Given something I can understand but may not be ideal, and something I don't understand but might be ideal, I have to go with the former.
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
There is no doubt that Bloch's point supersedes the general understanding of developers; or at least, did at the time of publication. That's why it set an important benchmark and an excellent precedent for the greater majority (who for some reason, worship Bloch as some divine creator of truth). I think the book is excellent and almost a requirement for any developer. I just wish publications like these (GoF is another one I can think of) didn't prevent ones ability to think independently. It's unfortunate that he didn't continue his journey to a greater clarity. Though, the publishing of a book has a primary agenda of making it to a bookshelf, and a secondary agenda of portraying a better correctness. One cannot rule out the possibility that there were external pressures.

I should probably crawl back into my box now
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Difference from design perspective