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. thanks.
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
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.