The Open-Closed Principle (OCP)  is and Object Orientated design principle put forward by Bertrand Meyer in 1988. It states that “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification“.

At a recent meetup of the London Software Craftmanship Community there was some discussion about the relevance of the principle today when compilers are super-fast and there is little overhead in revisiting existing code in the light of new requirements.

This got me thinking. That explanation didn’t sound right to me. What is behind this principle? Why shouldn’t we modify existing code?

One reason might be that it’s a lot easier to write completely new code rather than try and rearrange and add to existing code. I’ve seen this for real (haven’t we all) when the latter has been done for years and the result is a mess. Also it means retesting all the existing functionality – not difficult if the code is fully covered by automated tests – but if not you can bet that even very complete regression tests are going to miss something.

Yet there might be a valid reason for breaking OCP, says  Rafael de Azevedo.

According to the Single Responsibility Principle there “should never be more than one reason for a class to change”.  Says de Azevedo “Identifying, representing and separating relevant concerns is the fundamental principle for our design process.” 

Imagine a typical conventionally written application with a large amount of technical debt. There’s a form class (let’s say). The code behind not only presents the UI but retrieves the data, has a whole lot of processing in the click event of one of the buttons. Another button uses SMTP to create an automatic email… and so on. Not unusual at all.

The only way to modify this class without changing existing code would be to encapsulate it in a wrapper class. This would be far from ideal. Breaking the Open Closed Principle at this point would be the desired way to go. Instead of one class one would have a number- each with it’s own responsibility. A Presenter or ViewModel class to update and respond to the UI. Those 300 lines of code under the click button (the horror! the horror!) could be moved to a new class, or (as is most likely), the code refers to another class or classes then the code should be moved to that class. Unless that class is closed for extension, modification or anything else.. hmmm.

The automatic email functionality should also have it’s own class.  Suppose that it is this functionality which has a new requirement. How much easier (and cool) just to be able to modify this class and being able to leave the UI class well alone? It also means the new functionality is available in the 5 other places where the automatic email stuff had previously been cut and pasted.

It also makes unit testing a lot easier and focussed as each class can be tested on it’s own apart from the form class (which would now be a Composite).

The lovely outcome of this carving up the code into manageable slices is that we can zero in with surgical precision into the area which is open for extension rather than spending days trying to track down the bits in the existing code which would require changing.