We developers get to deal with change nearly every day. As your project progresses, stories or requirements are changed or added. And we’ve all been to the point where our code gets brittle or unmaintainable after too many changes and/or additions.
Let’s start with a metaphor. Let’s say your keyboard is broken and you need a new one. Luckily the keyboard is connected via a USB-connector to your computer, so you can replace it with another keyboard with ease.
But what if there wasn’t a common interface (USB) to connect your keyboard to a computer, for example if it was directly connected to the computer?
Indeed, you would either get an entire new computer or you’d be soldering your new keyboard onto your computer. None of which are ideal solutions to the problem.
This metaphor applies to programming in many ways, but arguably the most important principle that comes from this example is that you should program to an interface where possible.
In a lot of cases programming to an interface encourages the interchangeability of certain parts of your application. Thus it enables you to write flexible code, and anticipate for changes in domain logic.
If you’ve ever written or worked with an online shop you might have come a cross the problem that different countries have different tax rates. Each country has their own tax rate, which of course can change independently. When implementing an online shop, this problem cries out for a flexible solution, and you need to think of a durable strategy to solve this problem.
A good way to do this is to look for commonalities of the different calculations. It is not hard to see that every tax calculation has nothing more than an in- and output number. As long as the tax is calculated correctly, the calculation itself is not really important to the system.
These commonalities are the things you define in the interface, in this case we’ll call the method calculateTax. By programming each country-specific implementation to the interface (TaxInterface) the Order does not need to know (or worry) about the outcome of TaxInterface::calculateTax(). The only thing that it needs to do is instantiate the approperiate implementation, which is out of the scope of this post.
See Diagram 1 for a clarification.
This solution is defined as the “Strategy pattern”, and it is about anticipating on (potential) change of features. In the example it is fairly easy to add a tax implementation for another country, while you have to make only small changes to your existing code.
I hope this example demonstrated the reason behind programming to an interface and and the purpose of the Strategy-pattern in a fairly simple manner.