Why Interfaces?
In a previous post, we looked at the contracts formed by interfaces. Today, we’ll look at some of the advantages that come when developing with interfaces:
-
Interfaces hide all details of the implementation’s inner workings from the client. This allows for flexibility in implementation. For example, the consumer doesn’t know if the implementation is single-threaded or multi-threaded. And the interface doesn’t say what approach will be used to do the work, leaving you free to innovate. An interface just promises an end result based on the contract. This also allows the end user to be more productive since they don’t have to understand the details behind the scenes.
-
The implementation can change in the future without affecting the consumer. Perhaps a component is difficult to come by or is prone to failure, or perhaps there is a much more efficient implementation available. You can swap out the component with another that adheres to the same interface.
-
Multiple implementations can be created and interchanged without impacting the end user. I’ve used this technique in the past to switch between multiple SMS vendors based on the destination where the text message would be sent so that I could get better pricing rates or increased reliability. This concept also reminds me of a story from a friend of mine who worked at a Fazoli’s many years ago. He told me about how every now and then a manager from a nearby Olive Garden would come to the Fazoli’s and purchase boxes of breadsticks in bulk to make up for breadstick supply shortfalls at his own restaurant. The Olive Garden patrons were none the wiser. The Olive Garden menu promised endless breadsticks, and that’s what they received.
-
When the system is under development, interfaces can be used to compress the schedule of the project. Let’s say you cannot perform work on a module in a system until work on another module is completed because one depends on the other. Work on both modules could be done in parallel as long as the two developers or teams involved can agree on a contract or interface that both sides will adhere to. One side will agree to implement their work according to the interface, while the other side agrees to consume based on the interface. This allows for compressing the schedule, shortening the overall length of the schedule due to the introduction of parallel work in place of work being done in sequence.
-
Interfaces can provide a facility for testing areas of the system independently from one another. Interfaces allow for substituting test doubles, emulators, or simulators in place of real implementations. This allows for testing scenarios that may be difficult or impossible to test otherwise. For example, what will the system do when the database server is turned off? Do we go turn off the database server to test this scenario? Absolutely not. Simulate it instead.
What scenarios have you encountered where interfaces were useful?