Interfaces vs Abstract classes

Navigation

Reading::Blogs

Reading::Books

This is a question that keeps coming up, time and time again.

This post is probably going to cause renewed debate on the subject; which is well, GOOD!

So to Interface or not, that is the question....

In order to answer this I feel we should take a quick look at the basic difference's between an Interface and an Abstract class, perhaps this will provide the answer we're looking for.

What is an Interface?

An interface is a contract, a specification that concrete classes MUST follow. It defines method signatures but cannot have any implementations; the latter must be provided by the classes that implement the interface.

C# differs from C++ in this regard because C++ lacks native language support for interfaces. As a C++ programmers you have to create an interface by defining an abstract class with pure virtual methods.

So what then you ask is an abstract class...

An Abstract class lets you define some behaviors and force your subclasses to provide others.
For example, if you have an application framework, an abstract class may provide default services such as event and message handling. Those services allow your application to plug in to your application framework. However, there is some application-specific functionality that only your application can perform. So instead of trying to define these behaviors, the abstract class can declare abstract methods.

So, now that we know the differences between Interfaces and Abstract classes when do we use which?

1. multiple inheritance
A class may implement several interfaces but can only extend one abstract class.

2. default implementation
An interface cannot provide any code at all, much less default code. An abstract class can provide complete code, default code, and/or just stubs that have to be overridden.

3. adding functionality
If you add a new method to an interface, you must track down all implementations of that interface in the universe and provide them with a concrete implementation of that method.
If you add a new method to an abstract class, you have the option of providing a default implementation of it. Then all existing code will continue to work without change.

4. is-a vs -able or can-do
Interfaces are often used to describe the abilities of a class, not its central identity, e.g. an Automobile class might implement the Recyclable interface, which could apply to many otherwise totally unrelated objects.

An abstract class defines the core identity of its descendants.

If you defined a Dog abstract class then Poodle descendants ARE Dogs, they are not merely dogable.

Implemented interfaces enumerate the general things a class CAN DO, not the things a class IS.

This to me is the ultimate decision factor between inheritance and interfaces.

So that should make it completely clear as to when to use an Interface or an Abstract class, Or does it?

Posted: Nov 07 2005, 01:03 PM by Ryan CrawCour | with 10 comment(s)

Filed under: Geekie

Comments

grmAbay said:

I'll start with a quote from the cover of the fabulous book 'Head First Design Patterns':
"See why Jim's love life improved when he cut down his inheritance".

Always prefer Aggregation over Inhertitance! In the first chapter of the book, a great example was given of why inheritance adds possible bugs in future versions. If I remember well, the example was as follows:
*********
An abstract Duck class was made. A lot of subclasses were added which implemented methods for drawing the ducks on screen, but they all Quacked, so it made sense to implement Quack() in the abstract superclass.

One day, marketing wanted to show a demo for a potential customer, but the ducks all had to fly too for the demo (typical for marketing: it had to be done before friday). The developper added a generic Fly() method to the abstract class (who wouldn't?).

The demo was a disaster because all ducks flew. Even the DecoyDuck. Also, a bug was notified: a rubber duck quacked where a squeak was expected.
*********

The solution to the problem was to use the Strategy pattern, where Ducks all had fields (aggregation) that implemented the interfaces IFlyable and IQuackable.

This is not an argument about Interfacing versus Abstraction, but it illustrates the point that abstraction should be used with care. Special attention is needed if the abstract class is likely to evolve during later maintenance.

In this example, it doesn't matter if you use an abstract Flyable and Quackable class or an IFlyable and IQuackable interface. The point is, abstraction must NEVER be overused.

# November 7, 2005 6:20 PM

Ryan CrawCour said:

Yes except that i would've made a base class called Duck and have my various types of ducks inherit from that. I would've then added Fly and Quack to the base class.

The only problem with this comes when the various types of ducks do not fly and quack the same. I suppose a particular type of duck could override the base Fly or Quack if it wanted to be different.

Again this just highlights the similarities between the two and why there is no definite right or wrong.

I say each to their own, they each have a place in OO programming and when used correctly are incredibly powerful.

# November 8, 2005 1:04 PM