At CQL, we have biweekly developer meetings where all the developers get together and talk about anything we've found to help us do our work. This includes tools, libraries, techniques, whatever. A couple of weeks ago we started going over design patterns. A few of us know about them and occasionally use them, but we have several developers that don't, which is something we would like to change. So the first meeting we covered the Factory pattern and the Command pattern. This past Friday we were going to continue with the patterns discussion by talking about Facade and Decorator, but while considering examples and what to talk about, I realized that Decorator especially relies on explicitly designing to Interfaces (Patterns in general do, but many of the other patterns can be more implicit about it via inheritence). After discussing it with Chad, we decided it would probably be better to spend a meeting talking about Interfaces, hows and whys, before continuing with the design pattern meetings.
There are probably a few hundred articles on the net already about the importance of designing to Interfaces, but I want to gather my thoughts here so I can hopefully provide a good presentation on it in two weeks.
So first, what does designing to an Interface mean? Fundamentally it means that when I write a piece of code that depends on other objects/methods, I don't directly reference those objects/methods, but instead reference the idea of those objects/methods.
Why would we want to do this? Well, there are many reasons, but they all boil down to one real core reason, and that is coupling. When you design to an Interface, you are making your code less tightly coupled to the objects/code that you are referencing. The two primary benefits for this are code reuse and code extensibility.
Code reuse is enhanced because if I have written my code to depend on only the idea of the other objects/methods, then I can literally cut and paste my code from one project to another and not have to make any changes to that code at all (or even better, I could roll that code up into it's own assembly and just add a reference, but that is the same as cutting and pasting). So any tests that I've written for my code provide additional value, as well as the confidence of knowing that it has been working in the first project for a while, so it will continue to work in the new project. Additionally, if I add any additional functionality to the code when I bring it to the new project can easily be brought to the original project, giving us a two-way reusability path.
Code extensibility is offered because I can now switch out the implementation of the objects/methods that my code depends on without worrying about breaking my code. So, for example, I can make my code work with any data backend I want (ie, SQL Server, XML File, Web Service, etc).
That sounds great! How do we do it? Well, implementation depends on the language you are working with. We are a Microsoft shop, doing all of our work in C# and primarily working with ASP.Net. In this environment, we have essentially two methods of designing to Interfaces. The first (and IMHO best for this environment) is to use interfaces (duh :) ). The second is to use a base class (most likely abstract, though not necessarily). The reason I say interfaces is the better choice for .Net is because you cannot have multiple inheritence, but you can have a class implement as many interfaces as you like. Of course, there will be exceptions to this(aren't there always exceptions? :) ).
I've talked about all the good things that come from designing to interfaces, how about the bad things? The only bad thing I can think of is in a way a good thing, and that is that you should be very careful about adding properties/methods to an interface. The reason for this is that an interface is essentially a contract; You are saying "If you implement these properties/methods on your object, you can use my code." If you change the interface in any way, you are altering a contract that may be used in many places, and will involve making changes to all of the classes that implement your interface as well as (possibly) requiring changes to the code that works with your interface. So you should not haphazardly change an interface that is already being used. Like I said, this can be a good thing as it can make you think a little more about it, and maybe to come up with a better way (for example, making a new interface that inherits from the old one, thereby allowing all the existing code to stay the same).
Another topic that I think should be covered is things not to do with an interface. The first thing may seem obvious from the previous discussion, but make sure that you don't add unnecessary fields to an interface. What are unnecessary fields? Anything that your code does not directly reference is unnecessary. As an example, consider CreatedDate/ModifiedDate/CreatedBy/ModifiedBy fields that are quite commonly found in a database. These fields should very rarely show up in an interface, because you should not be using those fields in your code (aside from in the data persistence layer, which should be the only code that maintains those fields). By adding those fields to the interface, you are requiring anybody who wants to use your code to implement them, even though your code is not using them.
Another thing to avoid doing with interfaces is checking the type of the passed in object; Avoid code like "if (PassedInUserInterface is AdministrativeUser)." The reason is that if you later on want to create another interface that behaves like an AdministrativeUser, then you have to search out and update all of your if statements to be something like "if (PassedInUserInterface is AdministrativeUser || PassedInUserInterface is DomainAdministrativeUser)," or you are forcing the user of your code to follow inheritence patterns that they may not want (descending DomainAdministrativeUser from AdministrativeUser). Seeing code like this (or considering writing code like this) should immediately make you think of instead adding a property to the interface (remember to think this through of course :) ) and taking advantage of polymorphism. A better approach would be to add a property like "IsAdministrator", then the classes that implement your interface can set that as they like. This improves the readability, extensibility, and testability of your code, so do it (and avoid testing the type of your object)!
Anyway, how about an example or two? I'm writing this on my Mac, and as usual I am going to be too lazy to fire up Parallels and Visual Studio, so the following code comes with a Disclaimer: I have not attempted to compile this code, and it probably won't actually do so. In fact, there's a possibility that if you take this code and run it, your hard drive will have Lorem Ipsum written over every sector and your monitor will turn purple.
Don't worry though, it's not very likely.
So my first example is one that I've used in discussions with others often, though I've never really written it all out and fully realized it. It's a very common task that we have to write a login page for a project, and they almost always look exactly the same. Username, Password, Login button, error message when the info is wrong, and maybe a forgotten password button. In a typical project, this would all be written up and referencing the User(AppUser, Staff, ApplicationUser, whatever) class that corresponds to the project. Or maybe it's a quick login page that references a single username/password stored in the web.config. Whatever it is, it represents code that looks very similar every time you implement it. The method that gets executed when the user clicks the "Login" button probably looks similar to this:
protected void Login()
{
AppUser UserLoggingIn = AppUser.LoginUser(txtUsername.Text, txtPassword.Text)