CSC/ECE 517 Fall 2010/ch7 7e ab: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(34 intermediate revisions by the same user not shown)
Line 1: Line 1:
=Protected Variations Pattern=
=Protected Variations Pattern=
The Protected Variations pattern is a specific example of a [http://en.wikipedia.org/wiki/GRASP_(object-oriented_design) GRASP] [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern].


__TOC__
__TOC__


==Section 1==
==Description==
The Protected Variations pattern is a specific example of a [http://en.wikipedia.org/wiki/GRASP_(object-oriented_design) GRASP] [http://en.wikipedia.org/wiki/Design_pattern_(computer_science) design pattern].  It is very broad in its scope.  Any object that presents a potential instability within the system due to variations of type is implemented with an interface and [http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch3_3i_ls#Polymorphism_and_types polymorphism] (discussed in chapter 3) is used to wrap the type.[[#References|<sup>[2]</sup>]]  The interface could be a small enough to cover only one method or a very broad piece of the total subsystem.[[#References|<sup>[1]</sup>]]


Protected Variations addresses the problem of assigning responsibilities in such a way that variations that might occur do not have undesirable effects upon other elements in the system.
The solution is to identify the points of predicted variation or instability and assign responsibilities to create a stable interface around them. In this case, interface is used in the broadest sense. It might be a complete subsystem fronting a much larger set of variable subsystem.This pattern, or rule, is very broad and complex. There is an assigned reading that goes into depth on the topic. We will examine this pattern from the discussion of the reading.[[#References|<sup>1</sup>]]


The basic object-oriented programming concepts of data encapsulation, interfaces, and polymorphism are all mechanisms that are present in the programming languages for similar reasons as the Protected Variations pattern.[[#References|<sup>[3]</sup>]]  The variations that are addressed could be data type, data format, different calculations, different object types, etc.


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.[[#References|<sup>2</sup>]]
==Examples==
===Document Plugin===
Consider the example of an editor that is designed to open and edit different file types, as shown in Figure 1.  The document type can be implemented as a type in the core application and document plugins can be designed to implement the interface for specific document types.  As new document types are required, the responsibility for supporting the variations is shifted externally to the document plugin.


[[Image:DocPlugin.PNG]]


''Figure 1. Document Plugin''


In this case, the Protected Variations pattern is similar to the Adapter pattern.




===Medical Data Printing===
A medical data reporting system (Figure 2) is developed to take in different types of medical test results and print the results to a report.  Different medical results may need to be handled in different ways, with some being formatted as numbers, some indicating a pass fail, some represented on a graph, etc.  The medical result could be wrapped in an interface by the reporting system and implemented for each result type.


Protected Variations decouples clients from the changes in the system being
[[Image:MedicalResults.PNG]]
used.[[#References|<sup>4</sup>]]


==Section 2==
''Figure 2. Medical Report System''


==References==
[1] http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/ProtectedVariations.html


[2] http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)#Protected_Variations
==Advantages==
•New implementations of a particular module to handle a specific variation can be added to the software without impacting client software.[[#References|<sup>[3]</sup>]]


[3] http://www.objectsbydesign.com/books/larman_notes/6-DesignAndImplementationTechniques.html
•Coupling between different parts of the software system are lowered.[[#References|<sup>[3]</sup>]][[#References|<sup>[4]</sup>]]


[4] Craig Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition). Prentice Hall, Upper Saddle River, NJ, 2004
•The cost of changes to the system can be lowered by ensuring that new variations can be supported by only adding a new implementation of the interface.[[#References|<sup>[3]</sup>]]


•Extensions required for new variations are easy to add.[[#References|<sup>[3]</sup>]]


==TO BE REMOVED (included for development reference only)==
==Disadvantages==
7e.  Protected Variations pattern.  This is one of the GRASP patterns.  Wikipedia: 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.  Describe the pattern, and give examples of its use.
• Increases the complexity of the design by requiring the interface and implementations to be separate


• Forces the programmer to spend extra development time during initial programming development to ensure that the interface is generic enough to handle future implementations


ACM books
Authors. Title. Publisher, City of Publication, Year of Publication.


==References==
[1] http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/ProtectedVariations.html


Originality. Chapter is not constructed by copy-and-paste, but rather is the writer's own work. Nor does it duplicate the organization of Wikipedia's article, or any other description of the topic. Rather, it should be presented in a way that differs from each of the sources.
[2] http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)#Protected_Variations


Clarity. The language should be simple and basic. Sentences should be short enough to be understood by a student in this class without rereading. Jargon should be avoided, except for technical terms that are introduced before being used. For a more technical treatment, the reader should be referred to appropriate sources.
[3] http://www.objectsbydesign.com/books/larman_notes/6-DesignAndImplementationTechniques.html


Coverage. All relevant material should be discussed, at about the same level of detail. If it is too involved, it is OK to reference external sources, but the entire chapter should not consist of references. Earlier sections should not be covered in more depth than later sections.
[4] Craig Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition). Prentice Hall, Upper Saddle River, NJ, 2004
 
Organization. The chapter should begin with an overview suitable for readers who are new to the topic, and proceed from simpler material to more involved. The progression should be logical, and should not jump from one topic to another without transition.
 
Definitions. Definitions should be clear and concise, and should be supported by explanations or examples. Definitions should be just that--not descriptions. Definitions should should be composed by the author, not taken from other textbooks.
 
Examples. Examples should be clear, succinct, and unambiguous. Diagrams and realistic examples are encouraged, but diagrams need to be explained with accompanying text.
 
Citations. All major concepts should have citations to more detailed treatments. Citations should include a good mix of sources, such as Web sites, scientific papers, and books. Citations should be in a common format, such as ACM reference format; do not use just a Web link without any title or author.
 
Diagrams. If the coverage of this topic would benefit from diagrams, are sufficient diagrams included? Are they easily understandable and well explained?
 
Flow. Chapters should build on--and reference--earlier chapters. Coverage in this chapter should not duplicate earlier chapters, but use hyperlinks to refer to those earlier sections.
 
Accuracy. Is the information in this chapter consistent with other descriptions of the same material? Can any errors be identified? Is information purported to be factual indeed a matter of fact rather than opinion?

Latest revision as of 02:59, 1 December 2010

Protected Variations Pattern

Description

The Protected Variations pattern is a specific example of a GRASP design pattern. It is very broad in its scope. Any object that presents a potential instability within the system due to variations of type is implemented with an interface and polymorphism (discussed in chapter 3) is used to wrap the type.[2] The interface could be a small enough to cover only one method or a very broad piece of the total subsystem.[1]


The basic object-oriented programming concepts of data encapsulation, interfaces, and polymorphism are all mechanisms that are present in the programming languages for similar reasons as the Protected Variations pattern.[3] The variations that are addressed could be data type, data format, different calculations, different object types, etc.

Examples

Document Plugin

Consider the example of an editor that is designed to open and edit different file types, as shown in Figure 1. The document type can be implemented as a type in the core application and document plugins can be designed to implement the interface for specific document types. As new document types are required, the responsibility for supporting the variations is shifted externally to the document plugin.

Figure 1. Document Plugin

In this case, the Protected Variations pattern is similar to the Adapter pattern.


Medical Data Printing

A medical data reporting system (Figure 2) is developed to take in different types of medical test results and print the results to a report. Different medical results may need to be handled in different ways, with some being formatted as numbers, some indicating a pass fail, some represented on a graph, etc. The medical result could be wrapped in an interface by the reporting system and implemented for each result type.

Figure 2. Medical Report System


Advantages

•New implementations of a particular module to handle a specific variation can be added to the software without impacting client software.[3]

•Coupling between different parts of the software system are lowered.[3][4]

•The cost of changes to the system can be lowered by ensuring that new variations can be supported by only adding a new implementation of the interface.[3]

•Extensions required for new variations are easy to add.[3]

Disadvantages

• Increases the complexity of the design by requiring the interface and implementations to be separate

• Forces the programmer to spend extra development time during initial programming development to ensure that the interface is generic enough to handle future implementations


References

[1] http://web.cs.wpi.edu/~gpollice/cs4233-a05/CourseNotes/maps/class4/ProtectedVariations.html

[2] http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)#Protected_Variations

[3] http://www.objectsbydesign.com/books/larman_notes/6-DesignAndImplementationTechniques.html

[4] Craig Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition). Prentice Hall, Upper Saddle River, NJ, 2004

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7e_ab&oldid=42953"