Def. Software entities (classes, modules, functions, etc.)
Robert C. Martin
should be open for extension, but closed for modification
In object-oriented programming, the open/closed principle states that “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”
Usually, the first impression that comes out about this principle is confusion: it is really hard to say that you will write your code once and never change it. That almost never happens. That confusion is however natural and true. Then, what the author of this principle really wanted to say? Obviously, we cannot take this statement too literally. However, I found a way It can be rephrased:
“Write your code in a way that it minimizes or streamlines changes in particular places over time.”
In order to get some concrete result out of this conclusion, I would like to break it by some of software development stages:
- Domain knowledge
- Software design
- Implementation
- Maintenance
1. Domain knowledge
Having accurate and optimal knowledge about the domain will lead towards accurate anticipations on which are going to be the most critical parts of the system, in terms of business uncertainty and change frequency. When those critical places are identified, the most brainstorming should go into them – identifying and thinking through all the vulnerable pieces correctly will lay the foundation for open/closed principle in the next stage, where we can actually start applying it correctly (code example about contact details and addresses)
2. Software design
When critical parts of the system are identified and brainstormed, we should already have a pretty clear picture on how we will design that critical module: what the module parts are and how they will communicate. There is one golden rule that stand the test of time and technology:
“Start designing before coding: write and connect empty classes/methods, fill-in the details later.”
Often, the connections and dynamics between the module parts tell much more about those parts than we could have anticipated before. We can discover many new hidden responsibilities. They can be implementation responsibilities that will be encapsulated within original parts. Also, they may emerge as responsibilities of new standalone components. These details may turn out to be crucial in increasing chances that our code will be, at the end, ‘open/closed’ in many different ways.