Expanding on an article I wrote a couple of years ago where I explained interfaces in C#, I’d like to explain why people should use interfaces. I received an email from a reader of my ASP Alliance article. He understands how interfaces work, but he’s trying to see why so many people are raving wildly about their greatness. His questioning of them is great, because it really is not obvious why interfaces are useful. Anyone who says otherwise is just trying to brag.
A couple of years ago, you wrote an article for ASP Alliance called "Understanding Interfaces." Once again, I saw how the code works, once again, I failed to see how it will benefit me.
Here's where everything breaks down for me: You create an interface with just method, property and event signatures. Then you inherit them in a class, recreate these same signatures and write the code to implement these methods and properties.
So I’ll start by mentioning that nearly all patterns, practices, principles, etc. in software development are based on code reuse. One of the most important reasons for code reuse is change. Developers are always responding to and creating changes. We must mitigate the risks of change, identify where changes will occur, and we must make changes.
Right about now you might be thinking, “but interfaces don’t reuse code. They just force you to implement new code. Using inheritance would be the way to achieve code reuse.” You ate technically correct. You understand how interfaces work, but you’re not seeing why we use interfaces. Interfaces themselves do not give us code reuse at all, however, they enable us to achieve code reuse.
Remember that I said that we must identify where changes will occur. Making this identification allows us to isolate changes thus mitigating the risks of changes and allowing us to make changes. Isolating the places that change also allow us the reuse the code which does not change, so by keeping some parts separate we can reuse others. The interfaces are for the places we can’t reuse the code.
Interfaces are “places of change”. Each implementation of the interface is a variation on how that required piece of the puzzle could have been implemented. This is contrary to how you’ll see a lot of interfaces used. It is sometimes difficult to see this as the behavior of interfaces, because people overuse interfaces.
As I see it, I could have saved a whole lot of time by not creating the interface in the first place! I mean, it's not doing any work. I still have to create the signatures in the class. Why on Earth do people praise these things and call them the answer to multiple inheritence? They don't do anything!
It is mostly true that interfaces don’t do anything. As far as being executable code is concerned an interface is basically just a worthless extra step, so why would we use them? Declaring an interface is like saying, “there is more than one way that this behavior could be implemented, but interactions with this behavior should be done this way only.” Having that common “interface” allows us to use any of these implementations interchangeably.
When to Use Interfaces
Some people would recommend that interfaces should be used everywhere. I’ve heard people say that no variable should be declared with a concrete type if it can be avoided. That may be a valid point, but if you’re just learning how interfaces can be useful that is a bad approach. If you don’t see value in interfaces, you will certainly not see the value of them when people use them everywhere. This washes them out and obfuscates their purpose.
Interfaces are used for logic which will have multiple or changing implementations. This means that we should use them in places where we will out of necessity have duplicate logic. Using the interface is what allows us to do this. Take a look at this code for composing a letter.
public string ComposeLetter(string recipientName,
string messageBody, bool isFormal)
{
string messageText = string.Empty;
if (isFormal)
{
messageText += GetFormalGreeting(recipientName);
}
else
{
messageText += GetCasualGreeting(recipientName);
}
messageText += messageBody;
if (isFormal)
{
messageText += GetFormalSignature();
}
else
{
messageText += GetCasualSignature();
}
return messageText;
}
Notice how we have these flow control operators dictating how the code will execute. What will happen if we need to have a third option for greetings and signatures for family members? We might add another else-if or we might use a switch. Either way this code gets larger and changed every time.
However, if we identify the aspects of the code that are changing we can isolate them and mitigate the risks of changing the code by keeping separate the logic which has multiple implementations. Notice we have already used one form of encapsulation by keeping each of those pieces of logic in separate methods. The logic we haven’t encapsulated is the flow control.
We can create an interface for it. The best name I’ve got for now is IFormalityGenerator, which is not a great name, but it will do for now. I’ll create that interface with two methods: GetGreeting and GetSignature. Very simple interface. Now we can rewrite our method to look like this.
public string ComposeLetter(string recipientName, string messageBody,
IFormalityGenerator formalityGenerator)
{
string messageText = string.Empty;
messageText += formalityGenerator.GetGreeting(recipientName);
messageText += GetMessageBody();
messageText += formalityGenerator.GetSignature();
return messageText;
}
We now just make the decision sooner and only once which implementation we are using. If this is a formal letter we will use the FormalFormalityGenerator. If it is casual we will use the CasualFormalityGenerator. Down the road when we create one for family members we can just go and create an implementation for the FamilyFormalityGenerator. We’ve made it so we create new code each time instead of going and changing the existing code in this method.
The power of an interface is in its ability to encapsulate the volatile aspects of a program and isolate that which can be reused more easily.
Comments