CSC/ECE 517 Fall 2010/ch7 7e GS
Introduction
The Protected Variations pattern [5] is one of the GRASP patterns. General Responsibility Assignment Software Patterns (or Principles), abbreviated GRASP, consists of guidelines for assigning responsibility to classes and objects in object-oriented design.[1]
The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.
Protected Variation Pattern
This pattern mainly deals with the problem of designing objects, subsystems and systems so that any variations or instability in these elements does not have an undesirable impact on other elements. The Protected Variation pattern tries to address this problem by identifying points of predicted variation or instability and assignsresponsibilities to create a stable interface (or protection mechanism) around them.
That is an external object trying to modify another object can only do this by the means of a wrapper which wraps the object to be accesed. Thus this insulates the objects from any changes or variation to other objects.
Some of the standard practices motivated by this pattern are Data encapsulation, Interfaces, Polymorphism and Indirection.. Also the Protected Variation pattern in principle is very similar to the "Open-Close Principle" discussed in detail by Bertrand Meyer in [4] and also very similar to what David Parnas means by Information Hiding in [3].
An Example
One commercial example that we can look at that best illustrates the Protected Variations design principle is in the commercial industry of video games. Vendors who make video games make money by building complex 3D game engines, sound effects and AI(Artificial Intelligence) effects.These companies often produce many games using the same engine, and release the game on many consoles like for instance a XBox or a Playstation. This can be seen as implementing the Protected Variation pattern, in that
- If a game is to be ported to another console, the wrapper object will have to delegate3 D graphics drawing to different console-level commands.
- It makes sense in such a case to make changes only to the wrapper since the wrapper is simpler to change than the entire game and all of its facets.
Other Mechanisms motivated by PV
Craig Larman in [2] looks at some of the common mechanisms that exist which take motivation from the Protected Variation design principle. Several software components or systems that exist already such as Operating systems, video games use this mechanism either directly or indirectly.
Even Components such as brokers and virtual machines are complex examples of indirection.[2]
Uniform Access
Uniform access is a syntactic construct which allows languages to express both a method and field access in the same way.Languages such as Ada, Eiffel, and C# support uniform access. For example, consider a Rectangle class with public fields length and width as below
class Rectangle{ public: float length; float width private: ...... }
Now a reference such as Rectangle.length might either refer to the public field or might internally call a method length():float depending on the implementation. This means that the developer can change public fields to access methods without changing the client code.
Data Driven Design
Service Lookup
Interpreter-Driven Design
Reflective or Meta-Level Designs
Advantages
Protected Variations aim to reduce the undesirable impacts on objects that can be caused by variations and instability in other objects that might be related. The advantages of this design pattern are:
- Cost for changes is lowered.
- There is low coupling when the Protected Variations pattern is used.
- Easier to add new features and easier to adapt the existing features to a different platform since it requires only a change to the wrapper.
- If there are clients accessing a service from an object, new features or services can be added without affecting the clients.
References
[2] Protected variation: the importance of being closed, Larman.C, ISSN: 0740-7459, 89 - 91
[3] “On the Criteria to Be Used in Decomposing Systems into Modules”, Comm. ACM, vol.12, no. 2, Dec. 1972
[4] Object- Oriented Software Construction (IEEE Press, 1988)
[5] “Prioritizing Forces in Software Design”, Patterns Languages of Program Design, vol. 2, Addison-Wesley, 1996