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 adaptations 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 originated 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 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. Keeping the original class structure intact when the code is updated allows the original functionality to remain intact. As a result, impacts to errors in coding remain only in the new code. Debugging will be limited to the new code. This is where time is saved in maintenance. 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. They all allow existing code to have additional functionality without compromising the original functionality.:
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:
Class Rectangle {
private float height, width;
public Rectangle(float height, float width){...}
public float getHeight(){ return height; }
public float getWidth() { return width; }
public float area() { ... } }
Adding functionality to the existing code to allow for Swiss rectangles:
class SwissRectangle extends Rectangle {
private float hole_size;
public SwissRectangle(float height, float width, float hole_diam){ .. }
public void shrinkHole() { hole_diam--; }
public float area() { ... } }
Indirection:
Suppose a system relies on polling and writing data to a particular type of database. What happens when the need arises to change the type of database? (object-oriented vs. relational)
Problems can arise if our code interacts directly with the database and we decide to make the change.
class PersistentStorage {
private datatype data;
public insert (datatype data) { ... }
public update (datatype data) { ... }
public delete (datatype data) { ... }}
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.
Conclusion
The open-closed principle and information hiding are different terms that have the common goal of creating code that does not require modification of original classes to add new functionality. This allows everything within the original code structure to function as expected if features are added to the code. Addition is the only method of modification of code allowed if the principles are strictly adhered to. The advantage of being able to add functionality to existing code without breaking any of the original functionality should be obvious. The programmer can save time by limiting the amount of debugging and troubleshooting since the programmer can be reasonably assured that any errors will be limited to the added code rather the original code. Savings in time translates to more efficient (cost savings) and happier programmers.
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