OCP: Open/Closed Principle
Software entities should be open for extension but closed for modification
Open/Closed principle promotes the use of protocols to enable you to adapt the functionality of your application without changing the existing code.
Earlier Open/closed principle was defined by Bertrand Meyer in 1988:
“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”
This is such an entity can allow it’s behaviour to be changed without altering it’s source code.
Unfortunately, Bertrand Mayer proposes to use inheritance to achieve this goal:
“A class is closed, since it may be compiled, stored in a library, baselined, and used by client classes. But it is also open, since any new class may use it as parent, adding new features. When a descendant class is defined, there is no need to change the original or to disturb its clients.”
Inheritance introduces tight coupling if the subclasses depend on implementation details of their parent class.
Robert C. Martin and others redefined the Open/Closed Principle to the Polymorphic Open/Closed Principle. It uses protocols instead of superclasses to allow different implementations which you can easily substitute without changing the code that uses them. The protocols are closed for modifications, and you can provide new implementations to extend the functionality of your software.
The main benefit of this approach is that an protocol introduces an additional level of abstraction which enables loose coupling. The implementations of an protocols are independent of each other and don’t need to share any code. If you consider it beneficial that two implementations of an protocols share some code, then implementation can be provided in protocol extension.
A clever application design and the code writing part should take care of the frequent changes that are done during the development and the maintaining phase of an application.
The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged.
In many ways this principle is at the heart of object oriented design. Conformance to this principle is what yields the greatest benefits claimed for object oriented technology like reusability and maintainability.
A quote from Agile Principles, Patterns and Practices by Robert Martin:
Modules that conform to OCP have two primary attributes.
They are open for extension, means that the behavior of the module can be extended. As the requirements of the application change, we can extend the module with new behaviors that satisfy those changes. In other words, we are able to change what the module does.
They are closed for modification. Extending the behavior of a module does not result in changes to the source, or binary, code of the module. The binary executable version of the module — whether in a linkable library, a DLL, or a .EXE file — remains untouched.
TDD is not only about testing, more importantly it’s about design.
There are many design patterns that help us to extend code without changing it. For instance the Decorator pattern help us to follow Open Close principle. Also the Factory Method, Strategy pattern or the Observer pattern might be used to design an application easy to change with minimum changes in the existing code.
In the SRP, you make a judgement about decomposition and where to draw encapsulation boundaries in your code. In the OCP, you make a judgement about what in your module you will make abstract and leave to your module’s consumers to make concrete, and what concrete functionality to provide yourself.
There is a funny analogy regarding this principle, it states “Open chest surgery is not required when putting on a coat.” Means, we as programmers should not risk altering core functionality to add a simple feature and potentially compromise data integrity.
Example of OCP is explained in nice way in this article for calculating area:
Let’s consider another example to create library of form. Library provides few fields for label, textField and textView.
After some time, library got shipped and new requirement came to provide support for
If I add new cases in this enum and client is using
RowType in switch statement then existing code will break and user will move away from using library.
If we follow Open/Closed Principle then our system will be always extendible.
These are few examples of Open/Closed Principles, used by Foundation and UIKit Frameworks:
The open/closed principle is a guideline for the overall design of classes and interfaces and how developers can build code that allows change over time. By ensuring that your code is open to extension but closed to modification, you disallow future changes to existing classes and assemblies, which forces programmers to create new classes that can plug into the extension points.