When in Doubt, Create an Interface
One of the features of some modern object oriented languages derived from C++ is the use of interfaces. An interface is a class that has no concrete implementation and provides only an interface to access its resources.
Each interface needs to be implemented by some concrete class, but the advantage is that they make it very easy to separate implementation concerns. Thus, you don’t need to worry simultaneously about implementation and interface issues.
Interfaces are one of the things that has helped me to constantly create software that is easier to test, modify and that doesn’t rely on concrete classes. Interfaces may not be the silver bullet of object oriented programming, but they provide a number of advantages over programming over concrete classes:
- An interface is a contract between you and the rest of your application. This contract is guaranteed by the compiler, so it is not possible to change the services made available through your class without changing the interface.
- Creating an interface gives you an opportunity to think about what you class has to offer to clients. The formal step of making an interface requires that you think what is essential in a class and what is just nice. Remove what is not essential and you will have a solid foundation.
- Interfaces can be mixed. So you don’t need to worry if all functionality you need is not present in a single interface. You can always add additional interfaces to supply the required methods for a specific use case. With interfaces, you don’t feel trapped when creating new functionality in the same way as when you use concrete classes. Interfaces can be mixed and matched at will.
- Interfaces make software easier to test. Since there is no concrete implementation that you are tied to, you can freely change the code used by your testing classes by defining your own concrete class. This way, you can decouple testing of your code from the behavior of other classes in the application. It is much more modular and results in fewer headaches during testing.
Disadvantages of Interfaces
Interfaces have very few disadvantages, the only major one being that you need to spend some effort to maintain a separate entity. But modern programming tools have made this mostly a simple effort, so it is not as difficult as it used to be.
Another aspect of interfaces that is overemphasized is the performance issue of using virtual pointers?—?in the lingo of C++. You have to notice, however, that modern object oriented languages are based on virtual machines. Such languages have each method represented as a virtual pointer anyway, unless the system decides to inline the method (in which case there is no performance penalty). Unless you have extremely critical software (in which case you probably need to be using C/C++) you shouldn’t worry about such performance issues, because they can be better solved by the virtual machine.
Conclusion
Interfaces are a modern mechanism to improve the design of software. Despite this, interfaces are under-used by most developers. We should use interfaces as the default method of communicating between parts of our application, reserving concrete classes only for constructing objects (factory methods) and for classes residing in the same package.
I intend to write more about the issue of creating concrete objects through the use of factory methods, which is another important part of the application if you really want to make full use of interfaces. Stay tunned and we will discuss more of this in the future.
Further Reading
- Large Scale Software Design is a C++ book, but it teaches everything you need to know about separation of concerns between interfaces and concrete code. This is even more important in C++ than in C# and Java, because of the compilation issues in C++ code. However, the advice is completely applicable. Reading this book will make you more knowledgeable about interfaces than reading any other book in Java or C#.
- Effective C#: this book covers a lot of nice topics related to class design and use of interfaces. Recommended.
But what about you, do you think there is any advantage or disadvantage of interfaces that I didn’t mentioned above? Share this with us in the comments.
Similar Posts:
About the Author
Carlos Oliveira holds a PhD in Systems Engineering and Optimization from University of Florida. He works as a software engineer, with more than 10 years of experience in developing high performance, commercial and scientific applications in C++, Java, and Objective-C. His most Recent Book is Practical C++ Financial Programming.
The Interface Segregation Principle from SOLID priciples provides a useful guideline on creating lean and clean interfaces that resist bloat.
By sud on May 20, 2009
Please, don’t use/publish interfaces in your APIs! ;)
Interfaces are OK, when you use them after a very serious consideration. But publishing an interface is a common trouble, you are not allowed to change it anymore. You can not remove methods – your clients can call it. You can’t add methods – your clients may implement the interface and this would broke their implementation. And (of course) you may not change signatures for the same reasons.
Abstract classes are much more suitable solution in majority of situations.
By Satai on May 29, 2009
@Satai: hi, your points are very relevant. Of course there are some disadvantages in publishing interfaces, but this has to do with maintaining binary compatibility across libraries. It is something that you cannot get completely rid of when using statically typed languages.
Using abstract classes also has a lot of disadvantages, the biggest one being that you are tied to that implementation. Also everyone needs to inherit from that class, which limits usability. One common solution is to provide an interface AND an abstract class. You have to study each case to see what is more suitable.
By coliveira on May 29, 2009
@colivera: you don’t need to be tight to the implementation, abstract class can provide just abstract methods. But anytime later, you would like to add a method, you can provide it (of course with a basic implementation) and clients can provide their own implementation later.
Providing both interface and abstract class may be helpful in some scenarios (probably most notably, when you sometimes need some form of “multiple inheritance”), but it can not remove the main problem – you can not add methods into the interface, that can be implemented by your clients.
And I definitely agree with you, that this theme has no right solution, that fits every situation. Such a rule would be great, but now we need to use our brains and experience to decide every time.
(Btw: this problem affects source code level compatibility more than binary compatibility, at least at Java platform.)
By Ondra "Satai" Nekola on May 29, 2009