Chapter 9. The OpenClosed Principle (OCP)

Chapter 9. The Open/Closed Principle (OCP)

© Jennifer M. Kohnke

Dutch Door: Noun. A door divided in two horizontally so that either part can be left open or closed.

The American Heritage Dictionary of the English Language, Fourth Edition, 2000

As Ivar Jacobson has said, "All systems change during their life cycles. This must be borne in mind when developing systems expected to last longer than the first version."^[1] How can we create designs that are stable in the face of change and that will last longer than the first version? Bertrand Meyer^[2] gave us guidance as long ago as 1988 when he coined the now-famous open/closed principle. To paraphrase him:

^[1] [Jacobson92], p. 21

^[2] [Meyer97]

The Open/Closed Principle (OCP)

Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.

When a single change to a program results in a cascade of changes to dependent modules, the design smells of rigidity. OCP advises us to refactor the system so that further changes of that kind will not cause more modifications. If OCP is applied well, further changes of that kind are achieved by adding new code, not by changing old code that already works. This may seem like motherhood and apple piethe golden, unachievable idealbut in fact, there are some relatively simple and effective strategies for approaching that ideal.