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.

The term Open-Closed Principal is credited to having orginated from Dr. Bertrand Meyer and appears in his 1988 book Object Oriented Software Construction. This original version of the Open-Closed Principle achieved protection from variation by relying heavily on original class inheritance. This is often referred to as the Meyer's Open-Closed Principle.

In more recent years the Open-Closed principle is linked more closely to the use of polymorphism to achieve protection from variations. In this system abstract interfaces are commonly used and multitudes of implementations are used polymorphically as substitutes for the existing implementation which leaves the original code intact and operating as intended.

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.

Coding Examples

The following are typical mechanisms which illustrate protected variations:

Polymorphism:

In the below example from Larman's book, protected variations are illustrated via the use of polymorphism. Many tax calculator systems need to be integrated, and these external tax calculators provide for a point of instability in the program. Polymorphism allows for various ITaxCalculatorAdapter implementations to be created and collaborated with while protecting the system from variations in the external APIs.

Inheritance:

Indirection:

Confusion with Data Encapsulation

While the concept of protected variations is similar to the concept of information hiding, it should not be confused with data encapsulation. Data encapsulation is merely a technique used to hide design information. Protected variations can involve many techniques wherein the overall goal is to protect code from other areas of the code which are decided to be highly volatile and likely to have the capability of adversely affecting the program.

References

Larman, Craig. Applying UML and Patterns. Prentice Hall PTR, 2001.

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 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 http://www.netobjectives.com/resources/books/design-patterns-explained/review-questions

http://www.augustana.ab.ca/~mohrj/courses/2007.fall/csc220/presentations/25_GRASP2.ppt#270
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