More GRASP Patterns - PowerPoint PPT Presentation

1 / 30
About This Presentation
Title:

More GRASP Patterns

Description:

Indirection. Protected Variations. Introduction ... Indirection. Problem ... By adding a level of indirection and adding polymorphism, the adapter objects ... – PowerPoint PPT presentation

Number of Views:244
Avg rating:3.0/5.0
Slides: 31
Provided by: georg261
Category:

less

Transcript and Presenter's Notes

Title: More GRASP Patterns


1
More GRASP Patterns
  • Chapter 22
  • Applying UML and Patterns
  • Craig Larman

Prepared By Krishnendu Banerjee
2
Objectives
  • Learn to apply the following GRASP patterns
  • Polymorphism
  • Pure Fabrication
  • Indirection
  • Protected Variations

3
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

4
Introduction
  • In this presentation we will look at four new
    GRASP patterns
  • Polymorphism
  • Indirection
  • Pure Fabrication
  • Protected Variations

5
Polymorphism
  • Problem
  • Who is responsible when behaviors vary by type?
  • How to handle alternatives based on type?
  • How to create pluggable software components?

6
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.

7
Polymorphism
  • UML Notation for Interfaces and Return types

8
Polymorphism Example
  • NextGen POS application supporting multiple Tax
    Calculators is a polymorphic operation.

9
Polymorphism Example
10
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.

11
Polymorphism Benefits
  • Extensions required for new variations are easy
    to add.
  • New implementation can be introduced without
    affecting clients.

12
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?

13
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.

14
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.

15
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.

16
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.

17
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.

18
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.

19
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.

20
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.

21
Indirection Example
22
Indirection Benefits
  • Low Coupling between components.

23
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.

24
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 Parnass
    information hiding and Bertrand Meyers
    Open-Close Principle.

25
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, Javas Jini, UDDI.

26
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.

27
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.

28
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.

29
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.

30
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.
Write a Comment
User Comments (0)
About PowerShow.com