Interface vs Abstract Class

1. INTERFACE VS ABSTARCT CLASS
Ever thought of their differences in real time? This is the frequent important question asked in
the interviews. Many people give a canned response like “You can define default functionality in an
abstract class and you can just define functions in an interface”. The curve ball is thrown when you ask
“Why would you use one over the other?” That will earn you the ‘deer in headlights’ look. Some reply “I
never had to use that so I don’t know”. So what are the great differences these two entities have in
Software Development?
At the top level, there are a few basic differences. Abstract classes allow for default function definition.
This means that whatever class extends the abstract class will have access to this. If we have a base class
where all the classes will perform the same function, then we can define that in our Abstract class. An
interface is a list of functions or properties that if a class implements it, it will have to have those
functions defined within it. It is a situation of “Is-A” vs. “Can-Do-this”. Objects that extends an Abstract
class “Is-A” base class. Objects that implement “Can-Do-This”. Now if I asked this question and got the
answer, yes, that would be the correct answer. However, I want to know why one would want to use an
interface over an abstract class, and vice versa.
In this post I explain where exactly the interface is used and so do the abstract class.
Interface and its use:
• It is Purely Abstract
• It’s having Fixed Functionality
• If an Interface changed, all the underlined classes will change.
Example:
Inject Business Method to an Interface A (New Story or Feature)
Where to add it?
Belongs to Interface A? Not belongs to Existing Interfaces?
Add to Interface A Add a new Interface B
All underlying class changes May be used in new classes or some (not all) of the
Underlying classes of Interface A
Called Extensibility of Interface A Called Multiple Inheritance.
• This scenario is not applicable when Interfaces (fixed) are sold across Business.
o Example: Service Contracts

2. • This is used when no need of Massive hierarchical framework.
Example 1:
Inherits implements
Interface A Class B <--------------- Class B
Example 2:
Let’s have an interface for a Director and another interface for an Actor.
Public interface Actor {
Performance say (Line l);
}
Public interface Director {
Movie direct (boolean goodMovie);
}
• In reality, there are Actors who are also Directors. If we are using interfaces rather than abstract
classes, we can implement both Actor and Director.
• We could even define an ActorDirector interface that extends both like this:
Public interface ActorDirector extends Actor, Director {
...
}
• We could achieve the same thing using abstract classes.
• By using Abstract class would require up to 2^n (where n is the number of attributes) possible
combinations in order to support all possibilities.
Ex: ActorDirector, DirectorActor…..
Why to prefer an Abstract Class?
Abstract classes allow you to provide default functionality for the subclasses. Common
knowledge at this point. Why is this extremely important though? If you plan on updating this base class
throughout the life of your program, it is best to allow that base class to be an abstract class. Why?
Because you can make a change to it and all of the inheriting classes will now have this new
functionality. If the base class will be changing often and an interface was used instead of an abstract
class, we are going to run into problems. Once an interface is changed, any class that implements that
will be broken. Now if it’s just you working on the project, that’s no big deal. However, once your
interface is published to the client, that interface needs to be locked down. At that point, you will be
breaking the client’s code.
• Its contains Default Functionality & abstract methods
Concrete Methods
Used in Versioning by overriding the default functionality in new version (class that
extends previous abstract class)

3. • Abstraction used with polymorphism is called Versioning.
• If we have common functionality used in a hierarchy of classes then put them in Abstract class.
Whenever we need to override the existing functionality we should cut a branch of underlying classes
and inherit from parent abstract class (which contains common functionality).
Example: Some common functionality is used across the hierarchy B-C-D-E-F. If you want to change the
functionality how the D object works then you need to cut the tree and attach E-F to A.
Common Common
functionalit Abstract Class functionalit
y AA y
A
A
B
C
A Used
D
Overridden
With new functionality
Cut Tree
E E
F F
Frameworks are a good place to show when and where to use both an abstract class and an
interface. Another general rule is if you are creating something that provides common functionality to
unrelated classes, use an interface. If you are creating something for objects that are closely related in a
hierarchy, use an abstract class. An example of this would be something like a business rules engine.
This engine would take in multiple BusinessRules as classes perhaps? Each one of these classes will have
an analyze function on it.
public interface BusinessRule{
Boolean analyze(Object o);
}

4. This can be used ANYWHERE. It can be used to verify the state of your application. Verify data is
correct. Verify that the user is logged in. Each one of these classes just needs to implement the analyze
function, which will be different for each rule.
Where as if we were creating a generic List object, the use of abstract classes would be better.
Every single List object is going to display the data in a list in some form or another. The base
functionality would be to have it go through its dataprovider and build that list. If we want to change
that List object, we just extend it, override our build list function, change what we want and call
super.buildList();
Almost everyone knows that interfaces means you are just defining a list of functions and that
abstract classes has the option of providing default functionality. The snags come when you drop the
‘why would I use one over the other?’ Abstract classes and interfaces are some of the most important
fundamentals of object oriented programming. Just knowing the differences between the two is not
enough. When you can look at a situation and make a strong recommendation, you will know you have
a much stronger knowledge of object oriented programming. Also it helps during interviews.