SOLID, Part 2: Open / Closed Principle
In this five-part series, I’m covering each design principle laid out in SOLID. In this post, I am covering the Open / Closed principle.
The Open / Closed principle is hardest to argue for. In our SOA (service-oriented architecture) world, we try to avoid using inheritance as a method to change behaviors. We would tend to just update the service itself.
The Open / Closed Principle was created by Bertrand Meyer in 1988 in his book Object Oriented Software Construction. It has two components:
- A module is open for extension
- A module is closed for modification
In our SOA world, we take the Open / Closed principle as more of a derivative of information hiding – a concept that was laid out by David Parnas in his paper “On the Criteria to be Used in Decomposing Systems into Modules”. If we do a good job with information hiding, the calling code won’t need to know if the code has been modified or not. If we set ourselves up with a great DI (dependency injection) layer, our calling code will never know if we dropped a completely different module underneath.
We tend to focus mostly on the interfaces to our services, as they are the things that can affect upstream callers. Now we don’t hold to a “you can’t modify existing code” mindset, but changing an existing contract has to be thought through carefully. Changing an existing contract can cause upstream callers to change. We are always trying to minimize the scope of our changes.
We can also extend our services by adding new:
- methods to our existing services
- contracts interfaces to existing services
- properties to the existing data contracts
At Don’t Panic Labs, we don’t focus on the Open / Closed principle nearly as much as the other principles in SOLID. We care deeply about information hiding to ensure we only expose the minimum amount of information out of a service, and we try to keep those principles even when doing projects with Angular / TypeScript.
