Fat Agnus

The term “interface” is somewhat generic, so the first time I heard it; I was pretty clueless about what it meant. It wasn’t until I got really serious about OOP and Design Patterns that I started to figure out what it was all about.

You might think that if you use the keyword Interface in C#, then you are following the principle. The problem with this is that when GoF published the Bible on Design Patterns, they didn’t mean for it to be that easy, because it is a bit more conceptual than that.

So what does “Program to an interface” really mean?

This principle is really about dependency relationships which have to be carefully managed in a large app. – Erich Gamma

To put it in other words, you have to follow the OO concept of Encapsulation; the exposed part of a class is its interface. The important part here is that the interface represents “what” the class can do but not “how” it will do it, which is the actual implementation.

Let us look at an example where we are programming to an implementation.

1
2

PepperoniPizza myPizza = new PepperoniPizza();
myPizza.Eat(); // returns "mmm, pepperoni"

The problem with this is that the interface is tightly coupled with the implementation, to decouple it we would have to abstract the interface of PepperoniPizza. This can easily be done through a tool like Resharper that has refactoring support. To make an abstraction of the interface, you could either make an Interface or an abstract class.

“Program to an interface”, really means “Program to a supertype”.
– Head First, Design Patterns

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public interface IPizza
{
	string Eat();
}
 
public class PepperoniPizza : IPizza
{
	public string Eat()
	{
		return "mmm, pepperoni";
	}
}
 
public static void Main()
{
	// programming to an interface
	IPizza myPizza = new PepperoniPizza();
	myPizza.Eat(); // outputs "mmm, pepperoni"
}

We know it is a PepperoniPizza, but we can use the IPizza reference polymorphically, which means that we can reuse it. We could easily replace the instantiation of the PepperoniPizza with another type of pizza that implements the IPizza Interface. There are different opinions about the I-naming convention for Interfaces, I’m not religious about it, but I like the idea of using it.

The next step would of course be to replace the hard-coded instantiation of PepperoniPizza with some sort of a method.

Interface vs. Abstract class

Choosing between these two really depends on what you want to do, but luckily for us, Erich Gamma can help us a bit.

As always there is a trade-off, an interface gives you freedom with regard to the base class, an abstract class gives you the freedom to add new methods later. – Erich Gamma

You can’t go and change an Interface without having to change a lot of other things in your code, so the only way to avoid this would be to create a whole new Interface, which might not always be a good thing.

Abstract classes should primarily be used for objects that are closely related, whereas interfaces are better at providing common functionality for unrelated classes.

If you know that the subclasses will share some common implementation, then you should use an abstract class, because Interfaces doesn’t have any implementation of its members.

Interface vs. API

Once you have given out your code and you no longer have access to all the clients, then you’re in the API business. – Erich Gamma

The difference between an interface and API can be summed up pretty quickly with the above statement. Clients can mean a few things. It can be another group inside the company or it can be a customer. Once the API has been published, then you have to support it and make sure it doesn’t break.

A Final word

When you are implementing an interface or inheriting from an abstract class then you could say that you have a contract with the object. This of course means that the object will always follow the rules of one or the other. This type of contract will for example help us when we are using Dependency Injection or want to create a Mock object.

Thank you for your help Tobias :)

Further reading

An interview with Erich Gamma

A java guy talks about Interface vs. Interface

Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series)

Head First Design Patterns

How often have you found yourself in a situation where you have been troubled about the design of a function?

Personally, I would say, frequently. You can never be to sure if something will work and usability for me is one of the most important things.

As fare as I know, there aren`t very many software firms that test the usability of an application on a broad range of users, because it takes a lot of resources and most of them just want to get going – cause time is money. Therefore it is nice to draw on personal experiences, but also the experiences of others and there is written a few good books on the subject. The problem is, as I see it, that you seem to be missing something when you read the books, because they don`t dive into specific functionalities. It is nice to draw on what we call Web design patterns and Yahoo has a great collection of these.

Yahoo! Design Pattern Library

And if you are willing to spend some money, you could also buy one of the following rapports from Nielsen Norman Group

Usability publications by nngroup

Both the links contain great resources, but if you need a good book, then you should check out my Book review category.