
Say "No" to the Open/Closed pattern - sklivvz1971
http://sklivvz.com/posts/say-no-to-the-openclosed-pattern
======
sunir
The open closed principle is just a result of a deeper "law", Conway's Law:

"organizations which design systems ... are constrained to produce designs
which are copies of the communication structures of these organizations"\--
Melvin Conway (
[http://en.wikipedia.org/wiki/Conway's_law](http://en.wikipedia.org/wiki/Conway's_law))

Entities should be closed to modification by parties not responsible to
maintaining the code. Extension interfaces are used to rationalize the
interdepartmental dependencies in a streamlined way that lowers the
communications overhead of coordination, negotiation, and control.

That is pluggability reduces having to sit through meetings with agonizing
coworkers and being closed avoids having to yell at Bob from three floors down
who just borked your code base.

But anyway the bottom line is that the open closed principle is not a
principle but merely one common view of organizational design reflected in
code architecture.

Conway's law is more important because it is more predictive and more
powerful. You can refactor code or the human organization or the communication
between people.

------
heleph
I agree that the subclassing idea is a particularly bad one. For starters, to
subclass a class to be able to change it without changing the code is almost
certainly going to break liskov's substitution principle because most likely
your change is not going to be exactly functionally equivalent to whatever the
class really does.

I have worked on a couple of codebases with deep and complicated inheritance
trees and it has convinced me that inheritance is a bad idea for code sharing
and only really helpful for times when there is a clear case for polymorphism.
Mostly in those cases an interface works as well as a base class.

Still I don't think the open close principle is completely worthless. I've
also seen pieces of code that tend to change a lot (not might change, but
actually have changed) where new behaviour is constantly added in new if
statements. Validation logic is generally a good example of this. I think in
this case, being able to inject in new behaviour using an interface is much
preferable to adding another branch to an if statement.

The strength of Uncle bob's advice tends to be that it's very practical and
explicit, which makes it quite accessible to the people who need it most:
programmers without much experience. It's kind of a pity that this advice is
so wooly and that it's presented as subclassing (which is super bad advice),
missing the actual good advice that code is easier to write rather than to
change, which I think is true even in a system with unit tests.

------
EugeneOZ
Just emotions without argumentation.

~~~
Dave____
Is it emotional to say that the majority of classes are changed be directly
changing the implementation, not by sub-typing? Or that designing plugin
systems is not the norm? Did you read this or just look at the mullet picture?

~~~
EugeneOZ
I read that post and I don't agree that 'majority of classes are changed be
directly changing the implementation, not by sub-typing" \- it means you
change source code of third party libraries and it's very bad practice.

