GRASP

[jimin-kiim]

• Introduction
• Creator Pattern
• Information Expert Pattern
• Controller Pattern
• Low Coupling Pattern
• High Cohesion Pattern
• Polymorphism Pattern
• Pure Fabrication Pattern
• Indirection Pattern
• Protected variations Pattern

[jimin-kiim]

Introduction

• GRASP: General Responsibility Assignment Software Patterns
• typical tasks in constructing a sw with OOAD
  • identifying the requirements
  • creating a domain model
  • creating a design model
  • adding attributes and methods to the software classes
  • defining the interactions between the objects
  • -> where the GRASP can be helpful
    • guideline to assigning responsibilities to collaborating objects
• Creator Pattern
• Information Expert Pattern
• Controller Pattern
• Low Coupling Pattern
• High Cohesion Pattern
• Polymorphism Pattern
• Pure Fabrication Pattern
• Indirection Pattern
• Protected variations Pattern

Responsibility

• a contract or obligation of a class
• Knowing Responsibility
  • private encapsulated data
  • related obejcts
  • things it can derive or calculate
• Doing Responsibility
  • doing something itself
  • initiating action in other objects
  • controlling and coordinating activities in other objects
• responsibility can be implemented with several methods or one.
• assigning responsibilities, making better modularity should be considered

Modularity

• goal of design
• partitioning the system into modules and assign responsibility among the compoenents
• it reduces the total complexity a programmer has to deal with
• measure: coupling and cohesion
• coupling
  • inter-dependencies between modules
  • attribute referencing, method referencing, direct of indirect subclass, implementing interface
  • higher: classes rely on one another a lot.
  • -> forced changes occur due to changes in depending classes
  • harer to understand in isolation
  • harder to reuse
  • pursue low coupling
• cohesion: how strongly the elements in a module are related
  • related to SRP
  • higher: elements in the class are related a lot
  • easily understandable and maintainable
  • better code usability
  • low coupling

[jimin-kiim]

Creator Pattern

• guideline to assigning creation responsibility
• Q. make whom to create A
• A. assign the responsibility to B if one of theses is true
  • B contains or aggregates A
  • B records A
  • B closely uses A
  • B has the initializing data for A
• and if there's a choice, prefer "B contains or aggregates A"
• do not use this pattern when
  • using recycled instances for performance reasons
  • conditionally creating an instance from one of a family of similar classes
  • desired to outsource object wiring (dependency injection)
• related patterns
  • abstract factory
  • singleton

[jimin-kiim]

Information Expert Pattern

• most used principle in assigning the responsibilities
• basic principle in assigning the responsibilities
• "Assign a responsibility to the class that has the information needed to fulfill it"
• if the information is spread across the different objects -> interactions are needed
• it may conflict with Separation of Concerns
• helps information encapsulation
• lowers the coupling

[jimin-kiim]

Controller Pattern

• gesture from UI layer -> to the application logic in domain layer
• Q. "What first object beyond the UI layer receives and coordinates a system operation?"
• A. assign the responsibility to an object representing one of these choices
  • option1. Facade Controller
  • a root object that represents the overall system; a device that the software is running within, or a major subsystem
  • disadvantage:
    • bloating. the root object might hold too much responsibility
    • it might lower the cohesion.
    • -> so it can be better to choose option 2 in this case
  • option2. Use Case or Session Controller
  • a receiver or handler of all system events of a use case scenario or session

[jimin-kiim]

Low Coupling Pattern

• how to reduce the impact of change
• assign the responsibility so that coupling remains low.
• high coupling to stable global objects is not problematic. high coupling to application object is.

[jimin-kiim]

High Cohesion Pattern

• how to keep objects focused, understandable, and manageable and as a side effect, support Low Coupling
• option1. assigning all to the root object
• option2. delegate the creation responsibility to the class that executes the related method

[jimin-kiim]

Polymorphism Pattern

• how to handle similar variations
• who is responsible when behavior varies by type
• assign responsibility for the behavior using polymorphic operations to the types for which the behavior varies
• easier and more reliable than using explicit selection logic
• easier to add additional behaviors later on
• but it increases the number of classes in a design
• and it may make the code less easy to follow
• beware of avoiding excessive use for future-proofing against yet unknown. potential future variations

[jimin-kiim]

Pure Fabrication Pattern

• assigning a highly cohesive set of responsibility to an artificial or convenience behavior class that does not represent a problem domain concept something made up, in order to support high cohesion, low coupling, and resuse.

[jimin-kiim]

Indirection Pattern

• assigning responsibilities avoiding direct coupling
• assigning the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled.
• Adapter, Facade, Proxy, Mediator..

[jimin-kiim]

Protected variations Pattern

• how to assign responsibilities to objects, subsystems, and systems so that the variations or instability in these elements do not have an undesirable impact on other elements
• identifying points of predicted variation or instability and assigning responsibilities to create a stable "interface" around them.
• OCP == PV
• protecting the existing code and design against the change