NJIT More GRASP Patterns Chapter 22 Applying UML and Patterns Craig Larman Prepared By: Krishnendu...
-
date post
20-Dec-2015 -
Category
Documents
-
view
232 -
download
1
Transcript of NJIT More GRASP Patterns Chapter 22 Applying UML and Patterns Craig Larman Prepared By: Krishnendu...
NJIT
More GRASP Patterns
Chapter 22
Applying UML and Patterns
Craig Larman
Prepared By: Krishnendu Banerjee
Objectives
Learn to apply the following GRASP patterns: Polymorphism Pure Fabrication Indirection Protected Variations
Introduction
GRASP stands for General Responsibility Assignment Software Patterns. It is a learning aid of fundamental principles
by which responsibilities are assigned to objects and objects are designed.
We already learned about the first five GRASP patterns: Information Expert, Creator, High Cohesion,
Low Coupling, Controller
Introduction
In this presentation we will look at four new GRASP patterns: Polymorphism Indirection Pure Fabrication Protected Variations
Polymorphism
Problem Who is responsible when behaviors vary by
type? How to handle alternatives based on type? How to create pluggable software
components?
Polymorphism
Solution Polymorphism is a fundamental principle in
designing how a system is organized to handle similar variations.
When related alternatives or behaviors vary by type (class), assign responsibility for the behavior using polymorphic operations to the types for which the behavior varies.
Polymorphism
UML Notation for Interfaces and Return types
Polymorphism: Example
NextGen POS application supporting multiple Tax Calculators is a polymorphic operation.
Polymorphism: Example
Polymorphism: Contraindications
Developers may not critically evaluate true likelihood of variability before investing in increased flexibility.
Developers may indulge in speculative “future-proofing” against unknown possible variations.
Polymorphism: Benefits
Extensions required for new variations are easy to add.
New implementation can be introduced without affecting clients.
Pure Fabrication
Problem What object should have the responsibility,
when you do not want to violate High Cohesion and Low Coupling, or other goals, but solutions offered by Information Expert are not appropriate?
Pure Fabrication
Solution Assign a highly cohesive set of responsibilties
to an artificial class that does not represent a problem domain concept - something made up, in order to support high cohesion and low coupling and reuse.
Pure Fabrication: Example
Suppose there is a requirement to save the Sale instances in a relational database.
Per Information Expert, this responsibility would be assigned to the Sale class itself, because the sale has the data that needs to be saved.
Pure Fabrication: Example
But the above solution leads to: Low Cohesion: Including tasks not related to
the concept of sale-ness. High Coupling: The Sale class is coupled to
the relational database interface. Low Reusability: The general task of saving to
the database may be needed by other classes. Assigning it to Sale class causes poor reuse and lots of duplication.
Pure Fabrication: Example
A reasonable solution is to create a new class that is solely responsible for saving objects. This class is a Pure Fabrication.
Pure Fabrication: Contraindications
Behavioral decomposition into pure fabrication to object design and more familiar with decomposing or organizing objects is sometimes over used by those new software in terms of functions.
Pure Fabrication: Benefits
High Cohesion is supported because that only focuses on a very specific responsibility are factored into a fine grained class set of related tasks.
Reuse potential may be increased because of the presence of fine grained pure fabrication classes.
Indirection
Problem Where to assign a responsilibity, to avoid direct
coupling between two or more things? How to de-couple objects so that low coupling is
supported and reuse potential remains higher? Solution
Assign the responsibilty to an intermediate object to mediate between other components so that they are not directly coupled.
Indirection: Example
Tax Calculator Adapter These objects act as intermediaries to the
external tax calculators. By adding a level of indirection and adding polymorphism, the adapter objects protect the inner design against variations in the external interfaces.
Indirection: Example
Indirection: Benefits
Low Coupling between components.
Protected Variations
Problem How to design objects, subsystems and
systems so that the variations or instability in these elements does not have an undesirable impact on other elements?
Solution Identify points of predicted variation or
instability; assign responsibilities to create a stable interface around them.
Protected Variations
PV is the root principle motivating most of the mechanism and patterns in programming and design to provide flexibility and protection from variation.
It is essentially the same as David Parnas’s information hiding and Bertrand Meyer’s Open-Close Principle.
Protected Variations: Mechanisms
Core Protected Variation Data encapsulation, interfaces,
polymorphism, indirection.
Data Driven Design Reading codes, class file paths, class name.
Service Lookup JNDI, LDAP, Java’s Jini, UDDI.
Protected Variations: Mechanisms
Interpreter Driven Design Rule interpreters, virtual machines, neural
network engines, logic engines. Reflective of Meta-level Design
Java introspector Uniform Access
Language supported constructs that do not change with change in underlying implementation.
Protected Variations: Mechanisms
The Liskov Substitution Principle (LSP) Software methods that work with a class T
should work with all subclasses of T.
Structure-Hiding Design Places constraints on what object you should
send messages to within a method.
Protected Variations: Example
In the external tax calculator problem, the point of instability is the different interfaces to the external tax calculators.
By adding a level of indirection, an interface, and using polymorphism with various adaptors, protection within the system from variations in external calculator APIs is achieved.
Protected Variations: Contraindications
The cost of speculative “future-proofing” at evolution point may outweigh the cost incurred by a simple design that is reworked as necessary. Evolution point is a speculative point of variation that may arise in future, but not specified in current requirement.
Protected Variations: Benefits
Extensions required for new variations are easy to add.
New implementations can be introduced without affecting clients.
Coupling is lowered. The impact or cost of changes be lowered.