CSC/ECE 517 Summer 2008/wiki3 6 esb

Protected Variation

Open-Closed Principle "Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification [Martin, p.99]"

Open-closed principle “Software should be open to extension but closed to modification” (Bertrand Meyer). The idea is to enhance functionality by making non-intrusive changes. Intrusive changes are changes that alter code that has been previously written; changing inside of classes. Rather, interfaces should be changed/extended rather than the implementation of classes.

Introduction

When programming code, care should be made to protect against change to the existing code. Information should be kept out of the grasp of components that could damage integrity. New design should be implemented at designated "variation" and "evolution" points. The pattern of Protected Variation involves identifying points of predicted variation and creating a stable interface around them.

Protected Variation is closely knitted with the Open-Closed Principle. When points of predicted variation are identified, the code becomes easy to extend/adapt ("open"), while the stable interfaces around these points provides for "closed" code, wherein modification will not affect clients. This stable interface surrounding the points of change also promotes the concept of Information Hiding, in that design information is hidden from other modules at the points of likely change.

Why use Protected Variation?

Protected Variation is a principle which can save much time and money. It is important to reduce the introduction of new defects, and in order to do so, the impact of change to a piece of code on the overall program must be minimized. Protected Variations help to introduce low coupling (i.e. minimizing the degree to which each program module relies on each one of the other modules), which in turn reduce change impact.

• Example 1

• Example 2

References

Larman, Craig. Protected Variation: The Importance of Being Closed. IEEE Software 18.3 (2001): 89-91.

External Links

http://codecourse.sourceforge.net/materials/The-Importance-of-Being-Closed.pdf

http://www.rgoarchitects.com/Files/ooprimer.ppt#288,9,OCP Example

http://www.cs.wright.edu/~tkprasad/courses/cs480/L3OOP.pdf

http://www.csci.csusb.edu/dick/cs375/16q.txt

http://www.cs.wustl.edu/~schmidt/PDF/design-principles4.pdf

http://davidhayden.com/blog/dave/archive/2005/06/04/1096.aspx

http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)

http://en.wikipedia.org/wiki/Open/closed_principle

http://www.openmymind.net/FoundationsOfProgramming.pdf

http://www.cs.umu.se/kurser/TDBC31/Overheads/L8-10_Advanced.pdf

http://www.nationmaster.com/encyclopedia/Open-Closed-Principle

Good General link: http://www.netobjectives.com/resources/books/design-patterns-explained/review-questions

Next very good: http://www.augustana.ab.ca/~mohrj/courses/2007.fall/csc220/presentations/25_GRASP2.ppt#270,5,Fig. 25.2 Applying polymorphism to Monopoly

http://www.nationmaster.com/encyclopedia/Information-hiding

http://www.rgoarchitects.com/nblog/CategoryView,category,ruby.aspx

http://www.cse.ohio-state.edu/~rountev/757/pdf/Principles.pdf

Back to the assignment page