BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Open-Closed Principle in SOLID Object Orientation Rules Challenged

Open-Closed Principle in SOLID Object Orientation Rules Challenged

This item in japanese

Lire ce contenu en français

Bookmarks

The Open-Closed Principle, OCP, part of the object-orientation SOLID principles, was recently criticised by Jon Skeet and Robert Ashton who both believes the principle, as it is defined, is doing more harm than good. Robert C. Martin, who identified the principles in the early 2000s, however, defends the principle, arguing that you have to look at the full description, not just the short definition.

The debate started by a tweet from Jon, author of C# in Depth, questioning the principle:
”I know that doubting things like OCP is pretty close to heresy, but it's just *never* made sense to me.”

Robert C. Martin in an answer looked back at his definition in the original OCP article:

Modules that conform to the open-closed principle have two primary attributes.
1. They are "Open for Extension". This means that the behaviour of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.
2. They are "Closed for Modification". The source code of such a module is inviolate. No one is allowed to make source code changes to it.

In his answer Robert admits that the definition was a bit overstated but also claims that the full article gave a more moderate explanation and that his newer articles has improved the definition.

Jon followed up on Robert’s answer arguing that the definition and description is too vague and unclear, these types of principles must be very carefully defined with the use of correct terminology to make the essence clear. Instead Jon prefers a similar concept coined by Alistair Cockburn, Protected Variation, which he thinks has a better description:
“Identify points of predicted variation and create a stable interface around them”

Robert Ashton later on also criticised the principle which he believes is the cause of many over-designed pieces of software. But he also sees areas where the principle makes sense, e.g. in areas that are repeatedly modified.
He then followed up with a look at each of the four remaining SOLID principles.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Missing the original context

    by Brad Appleton,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The various objections to OCP seem to be missing the key context that was part of the OCP as originally described by Bertrand Meyer in his OOSE book.

    The context was of a provider (or "supplier") trying to write a reusable "module" of software (e.g. APIs) for some other (3rd party) consumer to reuse. The consumers of your libraries and interfaces should not have to modify the supplier's code in order to reuse it. Otherwise they are basically having to make custom changes to supplier's codebase (assuming they even have the code - if not they'd have to reverse engineer it first) and this is a very undesirable additional support burden to have to "own" for a product you are wanting merely to consume and not have to also additionally support.

    Meyer was not assuming a waterfall process (as some suggested) but the same kind of iterative and incremental lifecycle that was typically being preached alongside object-orientation back in the late 80s.

    OCP still makes perfect sense in this context of module/component "suppliers" and their external consumers. The burden of supporting and maintaining the component should be on the supplier, not on the consumer.

    Even for open-source products where you might actually have access to the code, this is still strongly preferred over requiring customers to make custom-changes to your codebase (makes it harder to support the customers). And the consumers prefer not to have to do this as well. They might want the option of being able to do it if they choose, but they don't want to be forced to have to do that extra work and maintenance just to be able to (re)use it for its intended purpose.

    The problem here is that somebody for some strange reason presumed that OCP must apply internally to other members of the team that owns and supports/maintains the code for the components/modules being delivered. Of course the suppliers/maintainers of the code should be allowed to change it! And of course they should make it as easy as possible to do! (But that also implies minimizing the impact of such changes to their customers, which again supports OCP).

    I dont think the OCP is dead or less relevant today. On the contrary, it seems just as relevant as ever! I think people need to remember that context is a key part of understanding, and don't necessarily assume that something is universal (much less overstated) if they saw or took it out of context.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT