CSC/ECE 517 Fall 2010/ch7 7e GS: Difference between revisions
Dragon9786 (talk | contribs) |
Dragon9786 (talk | contribs) |
||
Line 13: | Line 13: | ||
== An Example == | == 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 [http://en.wikipedia.org/wiki/Xbox '''XBox'''] or a [http://en.wikipedia.org/wiki/PlayStation '''Playstation''']. | 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 [http://en.wikipedia.org/wiki/Xbox '''XBox'''] or a [http://en.wikipedia.org/wiki/PlayStation '''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 | |||
= Conclusion = | = Conclusion = |
Revision as of 01:40, 2 December 2010
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
Conclusion
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