By Topic

Protected variation: the importance of being closed

Sign In

Cookies must be enabled to login.After enabling cookies , please use refresh or reload or ctrl+f5 on the browser for the login options.

Formats Non-Member Member
$33 $13
Learn how you can qualify for the best price for this item!
Become an IEEE Member or Subscribe to
IEEE Xplore for exclusive pricing!
close button

puzzle piece

IEEE membership options for an individual and IEEE Xplore subscriptions for an organization offer the most affordable access to essential journal articles, conference papers, standards, eBooks, and eLearning courses.

Learn more about:

IEEE membership

IEEE Xplore subscriptions

1 Author(s)

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

Published in:

Software, IEEE  (Volume:18 ,  Issue: 3 )