Does the "Open for extension, closed for modification" principle make any sense?

Question

It looks to me like Bob Martin needed something starting with O to make SOLID and found in some old book this (possibly useless) Open/Closed principle.

How can Open/Closed co-exists with the Single Responsibility, that states a class should have a single reason for change?

If I want to follow Open/Closed in a long living system, am I supposed to have a chain of dozens/hundreds classes, each extending the previous?

Pentose

The answer to this question is "yes" which would make a pretty crappy answer... – Radiothermy

Even that answer is a useful data point :) – Pentose

This is probably way too open for SO - but I have found these two posts useful when thinking about SOLID: accu.org/index.php/journals/1957 and accu.org/index.php/journals/1957 – Deadlock

They complement each other. A) Classes should do only one thing, but B) if their behavior is likely to be extended, they should be written in such a way that they can be extended without being ripped open. Every time a class is extended, you should make sure it that is still adhering to A). If not, it is likely that it is time to refactor. – Landgrave

@Deadlock You linked the same page twice. – Pentose

also lostechies.com/joeocampo/2008/03/21/… – Harlene

@Pentose good spot. I meant Jon Skeet: codeblog.jonskeet.uk/2013/03/15/… for the 2nd one – Deadlock

Robert C. Martin codified the principles before the acronym existed. Michael Feathers added the acronym later. See the tag info for solid-principles. – Telencephalon

Answer 1

The Open/closed principle implies that you can create systems in which new features are added by adding new code as opposed to changing old code. In order to be perfectly conform to the open/closed principle one must have perfect foresight. For in order to create a system that is fully open to extension and closed to all modification one must be able to perfectly predict the future. One must know in advance what new features the customer will request in order to put extension points to the code.

Having said that we could develop systems that conform well enough to the open/closed principle. By using an iterative process with lots of feedback and refactoring we can improve the parts of the system that change most often by making them open to extension and closed to modification.

As Bob Martin says in one of his lectures: "We cannot completely conform to the open/closed principle. It doesn't mean we should simply give up on the open/closed principle entirely. It may be difficult to make the entire systems to conform to the open/closed principle but it's not difficult to make functions or classes or smaller components to conform to the open/closed principle"

Gogetter

Answer 2

I also came here wondering about the whole "Closed for Modification" bit but I've come to a conclusion that I feel is best demonstrated with an example:

public class FixedSizeCache {
    private int maxCacheSize = 8192;
    public FixedSizeCache() {
      // ...
    }
    // ...
}

The above example doesn't violate the Single Responsibility Principle but it violates the Open/Closed Principle in a fairly obvious way: whenever you need a FixedSizeCache of a different fixed size you would need to modify the source of the class.

In other words, we should strive to write code that doesn't violate the Open/Closed Principle in obvious ways but this doesn't mean we need to write code that is utterly locked in stone never to be modified (because business requirements change and that should be reflected in our code).

But if the same business requirement changes 7 times and you need to modify your code 7 times, you're probably violating the Open/Closed Principle and are due for a refactoring.

Feral

Answer 3

Beautifully formulated question!

If I want to follow Open/Closed in a long living system, am I supposed to have a chain of dozens/hundreds classes, each extending the previous?

This is exaclty what I observed some time ago on a "long living system"; dozens of classes extending by small bits the superclasses. On the other hand modern construction of python goes exactly egainst this principle, and I had the feeling the violation of Open/Closed of modern python was the root cause for the usefullnes and simplicity of many of python's libraries. So I checked SO, and found your question. Well formulated!

Constringe