13 May 2014

Open-Close-Principle considered (practically) useless

Underlying Goal Considered Valuable

In a recent blogpost, the honorable Uncle Bob once again discussed the merits of the famous Open-Close-Principle. Quote:

You should be able to extend the behavior of a system without having to modify that system.

I like and strongly support that idea. It's realization by plugin-architectures is useful in some cases, it's foundation in object-orientation is one of the few useful applications of inheritance.
I teach the OCP in classes and advice people inhale it like oxygen in their daily life.
It's a beautiful theoretical concept. In practice, it's mostly useless - sigh.

The Nature of Changes in Practice

Since more than 20 years I work with teams changing, enhancing or optimizing software systems. I've seen code in financial industry, insurance and banking systems, logistics, telecommunications, embedded systems and, of course, the web.
Changes were often corrections to previous requirements: (I quote real customers and product-managers in the following lines)

"aargh - we didn't mean it THAT way, please correct it to THIS way".

"Make it faster, whatever it takes."

)

"We need some new attributes in the view"

"You have to integrate the XYZ system urgently into our processing" (replace XYZ by SAP(c), Oracle(c) or any huge commercial software suite that you cannot integrate by just calling a simple API)

Too bad those requirements cannot be met by simply creating a new plugin to a nice-and-beautiful plugin architecture.
Too bad those requirements often invalidate yesterdays' assumptions and code.
The open-close-principle does not help me in those cases.
Those cases are the rule, the standard, normal.
Even if I (or other software engineers) had implemented plugin architectures - those wouldn't help with new attributes in some strange old-school UI or some backend insurance database.

Is Open-Close Applied in Real Systems?

Most productive systems I met (and I met many many dozens of them) don't have the notion of clear extension points. Many have been implemented by teams under severe cost or time restrictions without freedom to apply design principles - sigh again.
That's one reason we founded aim42 - to systematically improve (and hopefully help spread OCP application..).
@Uncle Bob: Thanx for your design principles - they make this (software) world a better place...

3 comments:

“The SOLID principles are not rules. They are not laws. They are not perfect truths. They are statements on the order of “An apple a day keeps the doctor away.” This is a good principle, it is good advice, but it’s not a pure truth, nor is it a rule.” (https://sites.google.com/site/unclebobconsultingllc/getting-a-solid-start)The intention of Uncle Bobs principles is to describe the basic notion behind decisions we make daily. They don’t need to be applied on large software systems, they also can be applied on single classes or even methods. That’s why I don’t see the OCP just as an argument for plugins. It is far more.

A complete other example where it helps is that you think twice before you change a methods signature because this would be a modification instead of an extension and can harm your system. I guess the OCP is the most underestimated principle of the five because it is, besides IoC which is often described wrong as pure dependency injection, the most complex one.

The SOLID principles help me personally far more when I refactor than most of the clean code rules because the principles can be applied to so many circumstances. They are so easy to learn but hard to master.

Hendrik, thanx for your comment. You're perfectly right - SOLID are solid principles, which I strongly support and suggest fellow developers to apply...

I tried to show the (practical) boundaries of OCP application - that practical change requests simply stretch beyond the applicability of OCP... wether you apply it only marginally support many kinds of such changes - at least in my experience.

My experience is in principle the same and I am arguing much too often with developers who are creating extensible, flexible and because of this more complex software than needed. Will refer to you blog post in future.

Nevertheless I am missing one point here. If you and the team are developing a framework or library, which is used by others, I think it is still worth to try the best regarding OCP and extension points. The effort to change interfaces and behaviour over teams/organizational boundaries is often that much higher, that in my opinion it is worth to try. And in my experience this works much better with technical/cross cutting libraries (like e.g. logging - no, I did not implemented one by my own) than functional related once (like insurance rate calculators).