You've written some code, tested, and shipped to production. Then you never have to modify that code again. Wouldn't that be great?
But putting the dreams aside... you have to modify, even multiple times, the code that has been written. And this in my opinion is one of the big challenges in software development: updating the already written code.
If you haven't taken the time, in advance, to think about the possible ways your code can change, you're quickly going to start to have problems with rigid and fragile code.
In this post, I'm going to discuss a software design principle that advises to program to an interface rather than an implementation to help you write code can be modified easier in the future.
Table of Contents
1. The list renderer
A good way to understand the benefits of software design principles is to follow an example and demonstrate visible benefits.
First, I'm going to show you an implementation that's not adapted to change. Then, by applying the program to an interface principle, redesign the component and demonstrate the advantages of the new design.
For example, you have the task of implementing a class ListRenderer. The class has just one method listRender.render(names), which renders an array of names into an unordered HTML list.
Here's how you could implement the ListRenderer class:
class ListRenderer { render(names: string[]): string { let html = '<ul>'; for (const name of names) { html += `<li>${name}</li>`; } html += '</ul>'; return html; }}
And now let's use the list renderer to render some names:
const renderer = new ListRenderer();renderer.render(['Joker', 'Catwoman', 'Batman']);// =>// <ul>// <li>Joker</li>// <li>Catwoman</li>// <li>Batman</li>// </ul>
The above implementation is a good solution if you want to simply render a list of names. But what if you need to change further this code, for example add sorting functionality?
2. Programming to an implementation
As I mentioned in the post introduction, there's a good chance that the already written code will have to be modified when new requirements arise.
Let's say there's a new requirement to also sort alphabetically the rendered names.
You can implement this requirement by creating a new sorter class, for example, SortAlphabetically:
class SortAlphabetically { sort(strings: string[]): string[] { return [...strings].sort((s1, s2) => s1.localeCompare(s2)) }}
where s1.localCompare(s2) is a string method that compare whether s1 comes alphabetically before or after s2.
Then integrate SortAlphabetically into the ListRender, enabling the sorting of the names before rendering:
class ListRenderer { sorter: SortAlphabetically; constructor() { this.sorter = new SortAlphabetically(); } render(names: string[]): string { const sortedNames = this.sorter.sort(names) let html = '<ul>'; for (const name of sortedNames) { html += `<li>${name}</li>`; } html += '</ul>'; return html; }}
Now with the new sorting logic integrated, the list renders the names sorted alphabetically:
const renderer = new ListRenderer();renderer.render(['Joker', 'Catwoman', 'Batman']);// =>// <ul>// <li>Bane</li>// <li>Catwoman</li>// <li>Joker</li>// </ul>
Now let's look closer at the sorter instantiation line:
this.sorter = new SortAlphabetically();
This is programming to implementation because ListRenderer uses a concrete implementation of the sorter, and exactly SortAlphabetically implementation.
Is programming to an implementation a problem? The answer depends on how your code will change in the future.
If you are sure that the list renderer will sort the names alphabetically only — and this requirement most likely won't change in the future — then the programming to the concrete sorting implementation is good.
2.1 Changing implementations
But you might have difficulties with the programming to implementation if the sorting implementation might change in the future, or if you need different sorting depending on runtime values.
For example, you might want to sort the names alphabetically in ascending or descending order depending on the user's choice.
When using programming to implementation you will start bloating your main component with the sorting implementation details. This quickly makes your code hard to reason about and hard to change:
class ListRenderer { sorter: SortAlphabetically | SortAlphabeticallyDescending; constructor(ascending: boolean) { this.sorter = ascending ? new SortAlphabetically() : new SortAlphabeticallyDescending(); } render(names: string[]): string { // ... }}
In the example above ListRenderer can sort the names ascending or descending. What kind of sorting is used depends on the ascending parameter.
You can see how complex becomes ListRenderer — it becomes bloated with the sorting implementation details.
What if later you'd like to add more sorting implementations? By referencing new sorting implementations in ListRenderer makes the class over-complicated with details it doesn't have to know.
Such design breaks 2 important software design principles.
Firstly, the design breaks the Single Responsibility Principle. The ListRenderer should be solely responsible to render the names, but now additionally it is also responsible to instantiate and select its right sorting implementation.
Secondly, adding new ways of sorting by directly modifying the ListRenderer breaks the Open/Closed Principle.
How to design the changeable dependency implementations? Welcome programming to an interface!
3. Programming to an interface
If you want to make ListRenderer more extensible and decoupled from a concrete sorting implementation, then you need to use the programming to an interface approach.
Here's what you need to do to improve the design of the renderer with different sorting mechanisms:
- Define the interface (or the abstract class)
Sorterthat represent the sorting behavior - Make the
ListRenderdepend on theSorterinterface, rather than the concrete implementation (SortAlphabeticallyandSortAlphabeticallyDescending) - Make the concrete sorting implementations (
SortAlphabeticallyandSortAlphabeticallyDescending) implement theSorterinterface - Compose a
ListRendererinstance with the right sorting implementation:new ListRenderer(new SortAlphabetically())ornew ListRenderer(new SortAlphabeticallyDescending())
The main idea of programming to an interface is to introduce a stable construction — an interface (or abstract class) — and depend on it. You also extract the logic of instantiating and choosing the implementation out of the main class.
3.1 Programming to an interface in practice
Ok, let's see how to put programming to an interface into practice to improve the design of list renderer.
- Defining the interface
Sortershould be relatively easy:
interface Sorter { sort(strings: string[]): string[]}
Sorter interface contains just one method sort() that sorts an array of strings. The interface isn't concerned about how the sort() method works: just that it accepts an array of strings and should return an array of sorted strings.
- Making the
ListRenderuse theSorterinterface is easy too. Just remove the references to the concrete implementations and use theSorterinterface solely:
class ListRenderer { sorter: Sorter; constructor(sorter: Sorter) { this.sorter = sorter; } render(names: string[]): string { const sortedNames = this.sorter.sort(names) let html = '<ul>'; for (const name of sortedNames) { html += `<li>${name}</li>`; } html += '</ul>'; return html; }}
Now ListRenderer doesn't depend on a concrete implementation of the sorting. That makes the class easy to reason about and decoupled from sorting logic. It depends on a very stable thing: the Sorter interface.
The presence of sorter: Sorter in the ListRenderer is what is called programming to an interface.
- Finally, making the concrete sorting class implement the
Sorterinterface is relatively easy too:
class SortAlphabetically implements Sorter { sort(strings: string[]): string[] { return [...strings].sort((s1, s2) => s1.localeCompare(s2)) }}
class SortAlphabeticallyDescending implements Sorter { sort(strings: string[]): string[] { return [...strings].sort((s1, s2) => s2.localeCompare(s1)) }}
4. Benefits vs increased complexity
You might say that programming to an interface requires more moving parts than coding to an implementation. You're right!
The biggest benefit, as you might see already, is the ListRenderer class using an abstract interface Sorter.
As such ListRenderer is decoupled from any concrete implementations of sortings: SortAlphabetically or SortAlphabeticallyDescending.
Now you can supply different implementations of sorting. In one case you can use sorting alphabetically ascending:
const names = ['Joker', 'Catwoman', 'Batman'];const rendererAscending = new ListRenderer( new SortAlphabetically());rendererAscending.render(names); // =>// <ul>// <li>Batman</li>// <li>Catwoman</li>// <li>Joker</li>// </ul>
In another case you can easily compose the ListRenderer to sort the names descending, without modifying the source code of ListRenderer:
const names = ['Joker', 'Catwoman', 'Batman'];const rendererDescending = new ListRenderer( new SortAlphabeticallyDescending());rendererDescending.render(names);// =>// <ul>// <li>Joker</li>// <li>Catwoman</li>// <li>Batman</li>// </ul>
But you can also choose the concrete sorting depending on a runtime value:
const sorting = someRuntimeBoolean ? new SortAlphabetically() : new SortAlphabeticallyDescending();const renderer = new ListRenderer( sorting);// ...
5. Conclusion
Programming to an interface is a useful principle to design a dependency that can change in time or different dependency implementations can be selected by a runtime value.
Programming to an interface usually requires the main class (e.g. ListRenderer) to depend on an interface (e.g. Sorter), and the concrete implementations (e.g. SortAlphabetically and SortAlphabeticallyDescending) to implement that interface.
The client of the main class (e.g. ListRenderer) can supply any dependency implementation it needs at hand, without modifying the source code of the main class (e.g. ListRenderer).
Note that programming to an interface comes with the price of increased complexity. Using it must be a wise and deliberate choice.
However, if you're sure that a certain part of your code won't change, then programming to an implementation is a good and cheap choice!
For example, if the ListRenderer will always sort the names alphabetically in ascending order: then stop at the design presented at the beginning of section 2. Do not add unnecessary complexity.
