May 31, 2006
The Open Closed Principle
On one hand, the Open Closed Principle (OCP), defined by Bertrand Meyer nearly 20 years ago, means that classes or components should be open for extension and adaptation. On the other hand, OCP means they should be closed to avoid cascading of changes to existing clients of the code.
In his paper "Protected Variation: The Importance of Being Closed", Craig Larman says that OCP demonstrated the original intent behind the object-oriented concept of information hiding.
OCP is explained both in Larman's paper as well as by "The Open-Closed Principle" by Robert C. Martin. I won't attempt to compete with them in terms of explaining OCP's meaning, but I would like to highlight some points and issues in regard to OCP.
It is easy to see the benefit of having a class that answers this principle: When you need to add a requirement, instead of breaking dependent code (and tests) you just extend it somehow and everything is nice and dandy. Furthermore, violating OCP can result in Rigidity,Fragility, and Immobility.
But how do you do that? The obvious (and naïve) answer is inheritance. Every time something needs to change just add a sub-class. The parent class is not changes and voilà. However, if you add sub-classes all the time you'd get "lazy classes" or freeloaders--sub-classes without a real reason for existence not to mention a maintenance nightmare.
Thus, sub-classing is an option but we need to consider carefully where to apply it. Other (more practical ) OCP preserving steps include:
To sum up, OCP is an important principle, keeping it results in better design. There are several practical and common steps we can take to help keep this principle and handle changes better.
Posted by Arnon Rotem-Gal-Oz at 07:16 AM Permalink
|
