When to use & when not to use ( Abstract Class & Interface )

[PIEBALDconsult]

Let it evolve as you develop it. Don't force it.

[Krishna Varadharajan]

Mr. Guy, I am very much clear about what you said. Now I have another doubt, Is that any rules that abstract class must inherit interface, than we need to override from abstract class ? I can create a normal class which can implement this Interface and use those methods. But here we have to create instance of the class to access those implemented methods. So overall you mean to say that, one of the reason to go for abstract class to avoid creating instance of the class ? krishna

[Lost User]

Abstract class and inheritance is all about building a hierarchy (or family) of classes while Interface is to enforce a contract. Consider this hierarchy of classes. You can create FlyingVehicle as an abstract class.

Vehicle --> FlyingVehicle --> Helicopter

Consider another hierarchy of classes. You can create Bird as an abstract class.

Animal --> Bird --> Eagle

While the two families of classes are distinct, both the the FlyingVehicle and the Bird classes can implement an Interface called IFlyable.

interface IFlyable {
void Fly();
void Land();
}

As you can see in this example, you created two distinct families of classes using Abstract classes and enforced the ability to fly using an interface.

[GuyThiebaut]

Hi Krishna, Please just call me Guy as Mr Guy is too formal for the codeproject ;) An abstract class does not need to implement an interface. An abstract class must be inherited as you cannot create an instance of an abstract class - think of an abstract class as something like a Feline, in Keith's excellent illustration, which is a concept and for which there is no such concrete existence. However there are tigers which are Feline and are very much concrete - so a tiger inherits from the abstract class of Feline. You can just create an abstract class and then inherit from that class to create your instances(without implementing an interface). An abstract class allows you to implement some very general methods such as the LookAround method in Keith's illustration which will not need to be overridden. Abstract classes are a means of writing less code and implementing polymorphism.

“That which can be asserted without evidence, can be dismissed without evidence.”

― Christopher Hitchens

[Keith Barrow]

Your code would work, but you have repeated LookAround() method, this increase your maintenance overhead if you needed to change one, the chances are you'd need to change the other. Obviously this is a simple example to try and make the principle clear so it doesn't stand up to close scrutiny. Additionally the abstract class adds a semantic meaning : these are all the things that my subclasses can do that are common to all of them.

Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^]

[Krishna Varadharajan]

Mr.Shameel, Can you please make those example's little clear, mean to say.. describing interface & abstract class with the same example by inheriting. krishna

[Krishna Varadharajan]

Thanks a lot keith, really appreciate your effort to make me understand :) krishna

[Keith Barrow]

Glad to be of help!

Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^]

[Krishna Varadharajan]

Explained very well, thanks a lot guy.. ;) krishna

[Lost User]

That's the point here, abstract classes and interfaces are not meant to be used interchangeably (although most programming languages allow you to do that). Classes are to build family and interfaces are to enforce contracts, nothing more, nothing less.

[Krishna Varadharajan]

Thank you... krishna

[jschell]

krishnavaradharajan wrote:

I know the functionality of Abstract Class & Interface.

Normally the "functionality" has nothing to do with the decision. You use them because they meet the design needs.

krishnavaradharajan wrote:

How to find out which is suitable for particular situation.

1. Collect some requirements. 2. Create a design. 3. Use the design to implement code. Step 3 is where you decide which one to use based on the objects of the design.