Open Open Principle

Please read the OpenClosedPrinciple first.

---

The Open Closed Principle states that entities must be open for extension, but not for modification.

This spurs thought about an 'Open Open Principle' to contrast with.

Denying access to modification prohibits fellow code operators (aka programmers) to be able to revise your code, and specifically question its workings and interactions with other entities! (Which in their turn, might be up for revision)

-- StijnSanders

You need to re-read what the OpenClosedPrinciple is about, you don't seem to get it yet. It applies only when creating new subclasses, not when changing the design.

---

As I understand it, the OpenClosedPrinciple is concerned with closing the interface to a class. The code itself can be refactored and looked looked at and prodded and poked, but just don't go changing the interface. If you need to extend it, inherit or delegate. With that interpretation, the OpenClosedPrinciple is compatible with CollectiveCodeOwnership. Of course, remember it's usually best to PublishInterfacesAtTheLastPossibleMoment?.

---

A couple things worth nothing:

Depending on the life-cycle of your product/libraries, the OpenClosedPrinciple may not apply. If a class is only used in one project (still under development), isn't a likely candidate for cross-product reuse, etc.... then go ahead and ReFactor it as necessary (including changing the interface), as you will have the ability to make the necessary changes to client code (and the UnitTests to back that up...right?)

If, OTOH, a class is stable, used on several different projects, then a particular project team ought not to go modifying it willy-nilly. Perhaps they can, but the risk of damage is much greater.

Possibilities:

• CopyAndPasteProgramming. Fork a new one from the base, modify to your heart's content. Won't break anybody else, but there are many good reasons (a doubling of code, maintenance headaches, etc.) why this is often not a good idea.

• Modify by inheriting; what BertrandMeyer (and others) recommend. Inherit from the class you want to modify, make whatever changes you like. Give it a new name. Doesn't break anybody; and the amount of new code that needs maintaining is now the difference between the two versions.

• Fork the code, use a VersionControlSystem to manage the fork. Better than CopyAndPasteProgramming, and you get to keep the old name; other clients of the class can easily "upgrade" to the new version by changing their version control configuration. Still have two separate versions to maintain. Some programming environments don't integrate well with VersionControlSystems.

• Change it for everybody; making sure that you break nobody. A lot of extra work; certainly not an example of DoTheSimplestThingThatCouldPossiblyWork.