CSC/ECE 517 Summer 2008/wiki3 6 esb

Protected Variation

The term protected variations comes from the need for the programmer to predict what in the code is likely vary in future adaptions of the code and prevent those variations from damaging the intended functionality of the code. At some time in the future the code is likely going to need additional functionality. The adding of functionality should not prevent the sections of code that currently work from continuing to do so while also allowing the new code to integrate and use the existing structure efficiently.

Protected variation is often linked to the Open-Closed Principle (OCP) and Information Hiding which all tend to have a final goal of code that is adaptable without damaging the integrity of original code and without alterations beyond additions to the original code.

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

Coding Examples

The typical mechanisms for protecting a system against variations.

Polymorphism example:

Inheritance example:

Encapsulation example:

Indirection example:

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