We covered the Open/Close principle in a recent lab, and it prompted a desire to cover some of the SOLID principles. I have determined however, that the length of this blog is short enough that I should dedicate it to a single principle at a time, beginning with the aforementioned Open/Close principle.
This particular object-oriented principle was outlined by Bertrand Meyer and states:
“…entities should be open for extension, but closed for modification.”
This of course, is a complex way of expressing a simple guideline for software development; which is that new functionality should be able to added without having to radically change existing code. The operative word, extension, is illustrative. If your code was a home, and you wanted to add more square-footage (read: functionality), you shouldn’t need to knock all the walls, or the whole thing, down to add a bathroom.
In the blog chosen, the author summarizes a talk he gave about the very subject. In it, he provides an example of a program he is developing for a company that calculates the total area of a set of rectangles. As the customer requests more and more shapes be added to the calculator, the original code changes drastically and gets longer and longer. This modification is opposed to this principle. In opposition, creating a Shape class that contains many children of different specific shapes – each with their own area function – with the ability to add more, eliminates constant modification of the main class, and allows for constant extensionability in the form of new shapes.
To say simply that code should be modular is unhelpful, as it is broad and the general definition of so many more good coding practices. Our class and homework provide another perfect example. Why should we have to constantly Override and rewrite portions of a superclass’ methods in each of its child classes to achieve proper functionality. Instead, in making a Quack/Fly Behavior interface we have established a broad mold that many new behaviors can be built off of; access to all of which is then granted by the relationship to the single respective behavior interface.
Therefore, the ability of code to be extended with new functionalities, using a single reference – in this case the behaviors, or shapes – instead of needing to rewrite or overwrite code is what is meant by extension; while keeping the existing code from needing constant revisions, is being closed for modification. Like the house example earlier, you should constantly be building out, not renovating what exists already.