Protected variation: the importance of being closed

The Pattern Almanac 2000 (Addison Wesley, 2000) lists around 500 software-related patterns, and given this reading list, the curious developer has no time to program! Of course, there are underlying, simplifying themes and principles to this pattern plethora that developers have long considered and discussed. One example is L. Constantine´s (1974) coupling and cohesion guidelines. Yet, these principles must continually resurface to help each new generation of developers and architects cut through the apparent disparity in myriad design ideas and help them see the underlying and unifying forces. One such principle, which B. Meyer (1988) describes is the Open-Closed Principle (OCP): modules should be both open (for extension and adaptation) and closed (to avoid modification that affect clients). OCP is essentially equivalent to the Protected Variation (PV) pattern: identify points of predicted variation and create a stable interface around them. OCP and PV formalize and generalize a common and fundamental design principle described in many guises. OCP and PV are two expressions of the same principle: protection against change to the existing code and design at variation and evolution points, with minor differences in emphasis