Open/Closed principle: the thin line between predicting the future and being provident
Open to extensions closed to changes: let’s delve into the Open-Closed principle, one of the 5 SOLID principles.
The SOLID principles are the “first five principles” of Object-Oriented software development described by Robert C. Martin. The word is an acronym coined by Michael C Feathers that serves as a reminder of these principles.
Here, specifically, I want to write about the second principle, the Open/Closed.
This principle states that a module should be closed to modifications and open to extensions; closed because those who use it should not be impacted by any changes in which they have no interest, open because it is almost certain that in the first version of the module there won’t be everything that will be needed over time. The focal point of this principle is to find the right balance between the concept of YAGNI (You Aren’t Going to Need It) and that of Plugin-Ability. The first tells us that we shouldn’t develop things we don’t strictly need at that moment trying to predict the future, while the latter says we should always have a design with planned extension points to add new features with as little change as possible.
A concrete example
For example, let’s imagine a Report class that has two methods: DisplayReport and PrintReport; this class is not closed because with each new view of the report the class will have to be modified.
A better design is a Report interface with an implementation for each view. In this way, a new view corresponds to a new module and each of them is closed.
The most complex of SOLID principles
Now that we cleared up the principle we can talk about it freely: I think this is the most complex principle to put into practice, in many ways.
I find the YAGNI principle to be fundamental to a good developer: there’s no point in developing something that you don’t need right now.
Even if you’re reasonably convinced that it will be useful in the future, you’re still trying to predict the future, and so you’ll probably fail. It’s much more effective and useful for business purposes to limit development to what we are certain is needed at that moment.
At the same time, though, we want a design that makes our lives easier when changes come along; the kind of design that embraces change, not the kind that becomes an impediment to it.
It’s obvious that writing code with all the best principles and practices will lead us to that result in a natural way; by relying on the “Make the change easy, then make the easy change” approach, we can refactor the code to make it easy to change for the required development and then proceed to make the change easy.
However, we want to emphasize the idea of Plugin-Ability, a concept that argues that our code should have ready-made hook points in its design. What might this mean?
As in the Report example, it means that we need to be clear about the concept of responsibility and especially about SINGLE responsibility, the first of the SOLID principles. If we decide that the assigned responsibility is the Report view, we must be aware that when the views become more than one it will be too much: it doesn’t scale. If instead we go down in detail and we define as responsibility the one of a specific type of view for that report, it is clear that the responsibility is now able to remain limited even to the scaling of the number of views.
A fundamental aspect, however, is to remember that this is still a decision that should be based on something concrete and not on a future hypothesis: in fact, it is always valid the Rule of three!
When the second view is requested, we can accept not to refactor code but, we must do it in a conscious way, keeping that part of the code under our radar and being ready to refactor it when the third view appears, as soon as it is requested.
In essence, this principle asks us to always keep the balance between being forward-looking and predicting the future; a balance between writing code with a design that makes our lives easier in the face of change and not blundering into predicting those changes (which might be more or less guessed depending on how knowledgeable we are about the domain we work in, but its still an actual prediction and therefore probably wrong).
