Open Closed Principle (OCP) is the O in SOLID principles. We already read about S (SRP) in previous post.

A software artifact should be open for extension but closed for modification

Robert Martin

To better explain this, let’s go through the example provided by author. 

Let’s say, we have a system that displays financial summary on web page. The data on page is scrollable and negative numbers are marked in red. Now let’s say the stakeholders ask that the same information be rendered into a report printed on black and white printer. Negative numbers should be surrounded by parenthesis and report should be properly paginated. 

This would mean the existing system should change, new code needs to be written. But to extent of the change would depend on the architecture. A good architecture would try to minimize the changes needed to extend functionality, ideally zero.

How can we achieve software that can be extended with zero change? 

1. By following single responsibility principle in identifying components that have different reasons to change and separating them. This would ensure that change in one component would not need change in another component. 
2. Organizing dependencies properly (dependency inversion principle)
3. Making sure the behavior can be extended easily

If our architecture looks like as shown in above figure, let’s evaluate if it follows OCP and is easy to extend – 

1. We have divided the whole architecture into components. There is View layer which is responsible to display the results, Presenter layer which is responsible to do the processing on data so that it becomes ready for Views. Then we have controller layer, which is responsible to get the data from the Interactor and send it to  the presenters. The Interactor is responsible to extract data from database and send it to controller. It acts as a layer between the controller and database. Each component has a single responsibility. 
2. The arrows are single directional. They show that component A depends on component B, eg. Web View depends on Screen Presenter. If there are any changes in View, there won’t be any changes needed in Presenter. If there are any changes in Presenter, there won’t be any changes needed in Controller and so on. Look how that Interactor is safe from any changes in Views/Presenter/Controller/Database. It also shows dependency inversion, both Controller and Database depend on it. 
3. There is like a hierarchy of protection based on notion of levels. Interactors are highest level, the are the components that deal with the central logic of system, and so are most protected. Controller are next in level, they might not be peripheral for Interactor, but are central to Presenters and are thus are less protected . Presenters are higher than Views, but lower than controllers and so are less protected than controller. Views are the least protected. This is OCP at architecture level.
4. Say we want to add another mobile view to this system, we would just need to add the Mobile Presenter and Mobile View, no other component would need to change, we can see system is easily extensible. 

Thanks for stopping by! I hope this gives a good preview into OCP. Eager to hear your thoughts and chat, please leave comments below and we can discuss.