Open/Closed Principle in OOP

Question

The Open/Close Principle states that "Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification".

Let's say I have a legacy domain class and the requirement is adding a new field in domain class so does it violate the Open/Close Principle of OOP. If so, how can we achieve this requirement without violating Open/Close Principle?

Answer 1

Systems are always changing. And we should change our software to new requirements. We need some:

1. new fields
2. new lines of code in some methods
3. new methods
4. new classes
5. new packeges

The OCP says:

Mayer (first definition in 1988, see reference 1) :

A module will be said to be open if it is available for extension. For example, it should be possible to add fields to the data structures it contains, or new elements to the set of functions it performs.

A module will be said to be closed if is available for use by other modules. This assumes that the module has been given a well-defined, stable description (the interface in the sense of information hiding). In the case of a programming language module, a closed module is one that may be compiled and stored in a library, for others to use. In the case of a design or specification module, closing a module simply means having it approved by management, adding it to the project's official repository of accepted software items (often called the project baseline), and publishing its interface for the benefit of other module designers.

But it is a little vague. (and maybe outdated - based on Robert C. Martin)

And Robert C. Martin notes about OCP see reference 2 in 2014:

Think about that very carefully. If the behaviors of all the modules in your system could be extended, without modifying them, then you could add new features to that system without modifying any old code. The features would be added solely by writing new code.

Therefore: If we can add new fields to existing source code without changing the existing code (only adding new codes), we do not violates OCP.

However, if we add a new field to source code and in the next steps we forces to change some parts of existing code, we violates OCP.

To evaluate our project OCP value, for example we can say: The number of lines of codes that we forces to change (in adding new field), shows the OCP value of our project.

Finally: To answer your question, the all parts of source code should be available to evaluate the OCP value.

Answer 2

In your case it is not a violation of OCP as long as those changes don't force changes to the class API and because it is about a domain class, not a service one.

A module is said to be closed when it's API has been established and published to the clients to use. Once you do that, you cannot change the API because it will break clients' code.

On the other side, you can modify the inner workings of the implementation classes seamlessly for the clients as long as the API remains the same.

When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad” design. The program becomes fragile, rigid, unpredictable and unreusable. The openclosed principle attacks this in a very straightforward way. It says that you should design modules that never change. When requirements change, you extend the behavior of such modules by adding new code, not by changing old code that already works.

Read this: https://web.archive.org/web/20060822033314/http://www.objectmentor.com/resources/articles/ocp.pdf

Answer 3

The Open/Closed Principle is to be "Open for extension, but Closed for modification".

The idea is that you design your system such that maintainers can add functionality by adding a new class (usually subclassing or implementing an interface), rather than having to modify an existing class.

In your scenario, if you need to modify the domain class by adding a field, that is a good example of a design that violates the Open/Closed Principle.

If you can fulfill the requirement by adding a new class (perhaps extending the domain class or extending some interface), then the domain class was designed in line with the Open/Closed Principle. Whether it is possible to do so depends on whether the domain class was designed for this or not.

If you have to modify the domain class anyway, you could consider refactoring the domain class so that future changes can be made by adding a class instead of modifying the domain class again.