File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes OO, Patterns, UML and Refactoring and the fly likes what is difference between interface and abstract class --- interview question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of REST with Spring (video course) this week in the Spring forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "what is difference between interface and abstract class --- interview question" Watch "what is difference between interface and abstract class --- interview question" New topic

what is difference between interface and abstract class --- interview question

Edward Chen
Ranch Hand

Joined: Dec 23, 2003
Posts: 798
if we have an interview question, the people ask us, what is difference between java interface and java abstract class, what conditions we should use which?

how should we answer?

Tulsi Rai
Ranch Hand

Joined: Jun 26, 2002
Posts: 55
Hi Edward,
As far as I understand, here are what I would say about them-

Interface -
It's an abstract class that is used to define protocols or contracts that are intended to be implemented or adhered to by the classes that extends it. It defines protocols ( members - variables or methods) that needs to be implemented by the classes that extend it. It is an abstract class which means it contains methods without body.

Abstract class - It's an abstract class because it contains some of methods or contracts that are not fully implemented and left to be implemented by it subclasses.

The difference between these two are that you used Abstract class if you have do partial implementation of contracts (methods) as Abstract Class can contain abstract methods and non-abstract methods which you can't do in interface as it can't have non-abstract methods. You use interface for multiple inheritance.

Hope it helps. I would like others to give some realworld insights into the circumstances that requires inteface and abstract class.
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1873
Hi Edward,

I completely agree with Tulsi's answer.

But sometimes interviewers are looking for answer which I would "never" give. That is- "with java interfaces you could simulate Multiple Inhiertance whereas with abstract classes you still run into problem when you think you need Multiple Inheritance".

So be sure to mention this reason as well along with what Tulsi explained.

You don't want to take chances with screwed up people's mind

Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1873
Oh and btw,

speaking of real world examples...

In RMI you have to create interfaces only to expose services. Abstract classes won't do the job.

Btw, I guess moderators will move this to other forum as it doesn't seem to be "OO, Patterns, UML and Refactoring" question...

sever oon
Ranch Hand

Joined: Feb 08, 2004
Posts: 268
I think the main difference is a statement of intent by the designer. When you write an interface, what you're saying is that piece of code will never, can never, have implementation directly tied up with it. An abstract class, even if it's purely abstract (no implementation), it could be changed at some point without fundamentally altering the design and have implementation added to it.

The main difference here is that classes that implement an interface are making a statement about what they are, and they're explicitly saying that while they claim to carry out certain behaviors, they do not make any guarantees or force their callers to know anything about *how* those behaviors are carried out. A subclass of an abstract class, on the other hand, is saying that it not only carries out the same behaviors as its parent abstract class, but that it does it in the same way as the parent class for any methods that are implemented in the parent and not overridden.

In OO, objects are expected to undergo modifications. If programs didn't evolve, then OO would be a useless endeavor...the point is to control change as applications evolve from one version to the next. When you write a class that extends an abstract class, you're basically saying that these two classes are now inextricably linked such that if the parent class has an implementation that changes in the future, say for a later version, then you most definitely want the subclasses to get those changes as well.

With an interface, it is a pure definition of the contract of the API presented by that interface. All you're saying there is that the implementing class will adhere to the contract presented in the interface, nothing more. If an application is well-designed, then contracts will be more "stable" (to use Martin Fowler's term, meaning it will not change--or change less, at any rate) than implementation over several versions of the codebase. If the contracts are more stable than implementation (it's nearly impossible for implementation to remain stable and only add code to a project to add functionality), that means the interfaces in your application will undergo very little or no changes while the classes undergo significant change.

Nailing down things that will not change in a design is good practice because it allows stable points of dependency--you can write 100 classes that implement an interface without having to worry that in version 2.0 you're going to have to change every one of those because the interface changed...that is, IF you design the interface properly.

I agree. Here's the link:
subject: what is difference between interface and abstract class --- interview question
It's not a secret anymore!