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-Closed 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

This type of design covers a wide variety of techniques, including reading codes, values, class file paths, class names, from an external source in order to change the behavior of or “parameterize” a system in some way at runtime. [2]

Impelementations such as style sheets, metadata for object-relational mapping, property files etc belong to this category.

In this design the system can be protected from the impact of changes to data, metadata, or declarative variations by externalizing the variant, reading the behavior-influencing data in, and reasoning with it. [3]

Service Lookup

The Service Lookup technique is in fact a special case of the data-driven design. These are generally used to do look ups for obtaining services. For example a naming service such as JNDI can be used to do service lookups to obtain services like Jini.

This approach uses the stable interface of the lookup service to protect clients from variations in the location of services. The classic Service Lookup and the interaction among the different components involved is illustrated in the figure. From the figure we can also see how the responsibilities are seperated and how a change can be implemented without affecting the client (or multiple clients if more than one is involved).

Interpreter-Driven Design

Interpreter-driven designs are design principles that some kind of interpreters which uses internal rules that read from an external source and execute them. The external sources could be script or language interpreters that read and run programs, virtual machines, neural network engines that execute nets, constraint logic engines that read and reason with constraint sets.

The advantage of this design approach is that we can write logic expressions externally to influence a system. Because the whole logic is externalized, the system is protected from the changes to the logic.

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

[1] Wikipedia GRASP patterns

[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

See Also

• Design Pattern
• Delegation Pattern
• Open-Closed Principle