Interfaces – The quest for re-use. [Comparison]

So we have seen 3 different types of solutions that can achieve the same result. But what are the advantages and disadvantages of these three? Let’s start by looking at the key characteristics that came to the forefront in the Polygon examples.

Fact : humans make mistakes. The important thing to notice here is that if you opt for making use of the Concrete class, the C# compiler expects you to remember to implement virtual members in the child classes. If you forget it, it will cause a runtime error! This is never good.

With Abstract classes and Interfaces you are “protected” by compile time checking to ensure that all implementations were done. This is surely a more prudent choice compared to the concrete class.

So how do we actually decide between Abstract classes and Interfaces? Let’s look at some pros and cons.

1. Highlighting the differences in the table above in terms of functionality Implementation:

Abstract Class:

The fact that it is permissible for Abstract classes to contain implementation code.  Why is this an advantage? The fact that this is permissible, gives us one of the principles of inheritance – namely re-use. This implies that ALL child classes are able to make use of the code that is contained in the parent class. Think of the GetPerimeter() method in the polygon examples.

Interface:

It is not permissible for an Interface to contain implementation code – ALL implementation MUST be handled by the Classes IMPLEMENTING the interface.

        2. In terms of Inheritance:

In C#, classes can only inherit from ONE parent / base class. For instance the

Octagon : IRegularPolygon.

In C#, classes can however implement MULTIPLE interfaces! In the C# base classes we find a typical example within the System.Collections.Generic.Dictionary

From what we have learned thus far it is expected that ALL the members of EACH interface implemented here must be implemented in the Dictionary class !

         3. In terms of Access Modifiers:

Abstract Class:

        With abstract classes it is possible to make use of access modifiers like :

♦  Public

♦  Private

♦  Protected

♦  Internal

This gives us a bit more flexibility to control the access to members when making use of an abstract class.

Interface:

With interfaces ALL members’ fields should remain without access modifiers, they are all public (accessible to all) by default. Adding an access modifier will result in a build error!

        4. In terms of Members:

Abstract Class: Within abstract classes any of the following are allowed –

♦  Fields

♦  Properties

♦  Constructors

♦  Destructors

♦  Methods

♦  Events

♦  Indexers

Interface:

Only the following are allowed in Interface –

♦  Properties

♦  Methods

♦  Events

♦  Indexers

The reason here is fairly logical as things like Constructors and Destructors usually contain specific implementation for a class which is not permissible here.