Principles of SOLID in OOP

Question

I am trying to prepare lessons about the five SOLID principles of Object Oriented Programming to high school students that have learned about polymorphism, abstract classes and interfaces.

However, I'm not sure how to properly explains the O (Open/close).

I cannot find a satisfactory explanation as to why it's ideal or important to write software (or APIs) that is open for extension and closed for modification.

As an analogy, I was thinking about a model of a house in a city. The municipality provides a list of things that have to be, and cannot be changed, but each household can paint their house or make small changes in some things​. I feel this analogy doesn't explain the principal in the right way.

What other analogies can I use to explain Open/Close?

Answer 1

The primary drive behind the open/close principle was to avoid having to update programs that used a library when changes were made to that library. Or, in other words, to enforce backward compatibility for old programs that used a library.

By not modifying the object (the close half) any code that uses the object according to the documented API, will always work.

By allowing extension of the object (the open half) new features, data, methods, etc., can be added to the functionality of the object to handle new uses for the object, or its subclasses.

Combining both means that the existing object, that almost fits the needs, can be enhanced to be useful in a new program, and still be used by the old programs, without needing to recode the old programs.

A common API that most high school students are familiar with is the telephone. It is going to be a very rare high school student who has never used a push-button telephone, including the "buttons" on the screen of a smart phone. So it is something that's well within the prior experience for those students.

The twelve standard buttons on the push-button telephone haven't been changed since the Western Electric model 2500 was introduced in 1968. The latest model smart phone still uses the same layout, and it still works the same (from the user's perspective), even if it's now a touch-sensitive screen rather than twelve physical buttons. They way on made a phone call in 1968 using a push-button phone, and they way one makes a phone call now with a smart phone is the same. It has not been modified. What you can do with those same twelve buttons, or simulated buttons on the smart phone, has been greatly extended. Sending text messages is only one change of many. There's no guessing what else those buttons might be extended to do, using new methods or new data. No matter what new extensions are added, the original will not be modified.

Answer 2

SOLID being a set of principles pertaining to OO programming, I don't think (but I'd love to be proven wrong) that you can find a "real life" analogy that will at the same time:

• convey the spirit of the open/close principle correctly
• be understandable by high school students (my gut feeling is that in some domains such as engineering or maybe law you could find such analogies but I'm not sure).

Rather you could use some software that they use everyday as an analogy (and that they understand really well). Here are some examples:

1. A web browser. The application in itself is closed. It consists of a fixed executable that performs a set of tasks in a particular way (displaying web pages). Anything on the system that needs to display a web page can just ask the browser to display it and it will always work. However, the behaviour of the browser can be altered (e.g. ad blocking, social media integration, etc...) through browser extensions. You don't need to recompile the browser (i.e. generate a new program) for that to work. The browser has hooks in its code that allows another program (the extension) to alter its behaviour or add a new functionality.
2. A media player. It supports a particular sets of input media formats. When a new format becomes available, one just needs to install a codec for the new format to be taken into account, without changing the media player itself.

The key point here is that although the module (class, web browser, media player) can be extended, the decision to enable extension has to be taken when the module is being developed (i.e. before it is closed). In statically typed OO programming this amounts to allow for a class to be extended by future code (e.g. no final in Java). Dynamic languages (in particular prototype based ones) such as Javascript or Python do not allow you to (easily) close a module. The user can always overwrite a method, access all fields, remove some (thus breaking existing code).