Abstract base class over interface


Currently I'm reading the book Framework Design Guidelines. This is one of the best books I have read in some time. Most books that cover design in general are one-sided and high-lights the author's beliefs and convictions. However, this book is very different. It gives suggestions about various framework design aspects and at the same time high-lights views/opinions of different people in the .NET team which doesn't necessarily conform to the guidelines. This makes the book a very interesting read.


One of the suggestions is "Favor defining classes over interface". While this is highly debatable, I agree to this in general. In this section I read a comment from Brian Pepin that reminded me of some framework code I saw long time back which convinced me that Abstract Base Classes are sometimes much superior to interfaces in defining contracts.


In that UI framework one of the requirements was that individual controls should support loading bitmaps that act as application skins with the following method prototypes....

void LoadBitmap(string fileName);
void LoadBitmap(string fileName, Color transparentCol);
void LoadBitmap(string fileName, int width, int height);
void LoadBitmap(string fileName, Color transparentCol,
int width, int
height);


The last method is the actual implementation and all the other methods fill in default values and passes it to this method.


In case this was defined in an interface as in

public interface ILoadBitmap

{
void LoadBitmap(string fileName);
void LoadBitmap(string fileName, Color transparentCol);
void LoadBitmap(string fileName, int width, int height);
void LoadBitmap(string fileName, Color transparentCol,
int width, int height);
}


All classes that implemented the interface had to do method parameter validation for all the 4 methods and call the last method passing the default value for the parameters not specified. Not only this becomes tedious if some 20 types of controls supported skinning, it leads to programmer error in which a wrong default value is passed in some of the controls. This is where Abstract Base Class comes in. Using ABC you can code this as

public abstract class SkinControl

{
public void LoadBitmap(string fileName)
{
Debug.Assert(!string.IsNullOrEmpty(fileName));
LoadBitmap(fileName,
Color.Magenta, -1, -1);
}
public void LoadBitmap(string fileName, Color transparentCol)
{
Debug.Assert(!string.IsNullOrEmpty(fileName));
LoadBitmap(fileName, transparentCol, -1, -1);
}
public void LoadBitmap(string fileName, int width, int height)
{
Debug.Assert(!string.IsNullOrEmpty(fileName));
Debug.Assert(width > 0 && height > 0);
LoadBitmap(fileName,
Color.Magenta, width, height);
}
public abstract void LoadBitmap(string fileName,
Color transparentCol,
int width, int height);
}

public
class SkinnedButton : SkinControl

{
public override void LoadBitmap(string fileName,
Color transparentCol,
int width, int height)
{
// Actual implementation


}
}


All the methods are implemented in the ABC and only the last method is made abstract. So for all classes that implements this abstract class the developer needs to implement the fourth overload of the method only. Most of the contract is directly coded into the ABC. This results in less code and less programming error.

Comments (10)

  1. Garry Trinder says:

    Using Debug.Assert without any hints on cause is lame.

  2. Mike says:

    "Using Debug.Assert without any hints on cause is lame"

    The point of the article is a discussion of Abstract Base classes versus interface for inheritance design.  

  3. Kevin Jones says:

    The way this is often done in Java is to define an interface and have a ‘default’ class implement the interface (called an adapter).

    As interfaces define a contract I much prefer to see them used when, for example, declaring method parameters, or when you need to define some sort of RPC mechanism.

    If you go with the interface with the default implementation you can stick to using interface based design that can be used in so many areas, and still have an implementation that can easily be re-used.

  4. Consider what type you should accept as a parameter. If you accept an interface, you open up the possibility of the developer extending your interface with their own, allowing them to do interface based programming all the way down through your API. If, on the other hand, you only accept a class (abstract or not) then the developer has no way of writing the following code:

    public void DoSomething(IMyExtendedInterface obj)

    {

     YourAPI.DoSOmething(obj);

    }

    which is really a pity, since code that is written close to your API should be able to raise the level of abstraction.

  5. TAG as MIKE had pointed out the point is to highlight ABC over interface and not show a true implementation. Thats why there is just a Debug.Assert. Most sample code do not even have error handling as it sidetracks the point being expressed. I had the debug.assert to indicate that parameter verification is also being handled in the ABC….

  6. yljia says:

    If C# supports "default interface method implementation" (which enables you to add default implementation for an interface method – but the method is still virtual, and the interface still cannot contain instance data), then you will be using interface instead of base class because interface is extensible. Anders actually has talked about this before – hope it be added one day in the future (beyond C# 3.0).

  7. fabricio says:

    You’re in vacation? I didn’t see more posts from you…

  8. So people have started noticing that I’m not posting 🙂

    Actually we are in the end game of VSTS and that sucked all time out from me. Now I have some time to start blogging again….

  9. fabricio says:

    😀

    Started not…I check your blog every day!

  10. Carsten says:

    Whether you use an interface or an abstract base class should depend on what you want to achieve.

    If you design a framework, users of your framework should only see interfaces in my opinion, that are instanciated by your framework by some sort of factory mechanism.

    For doing something like Error Handling I prefer the Security Facade – which just implements a specific interface with doing the error handling and then calls the implementor via the same interface. This concept is more flexible I think, because the implemented classes do not have a dependency on the error handling but can be "parametrized" with the Error handling through the Security Facade.

    But: All depends on the context. Do not over-engineer simple problems 🙂

Skip to main content