Software Modelling and Design

GRASP

GRASP

Table of Contents

GRASP: Overview and Interrelationship

Relationship between grasp principles

Benefits of patterns

Responsibilities

Creator

Problem: who should be responsible for object creation?

Solution: Assign class B responsibility to create class A if:

The more of these that hold, the stronger the implication.

Benefits: Low coupling

Contraindications:

Information Expert

Problem: How to decide which class to assign a responsibility to?

Solution:

Benefits: classes are

Contraindications:

Low Coupling

Problem: how to support low dependency, low change impact, and increased reuse?

Solution:

Benefits: code becomes

Contraindications:

High Cohesion

Problem: How to keep objects focused, understandable, manageable, while suppporting low coupling?

Solution:

Benefits: code becomes

Contraindications:

Cohesion in Monopoly

Controller

Problem: What first object beyond the UI layer receives and coordinates (i.e. controls) system operation?

Solution:

Benefits: prevent coupling between UI and application logic

Issues:

Facade vs Use Case Controller

UI Coupling

Better UI Coupling

Polymorphism

Problem:

Solution: when related alternatives/behaviours vary by type (class), assign responibility for the behaviour using polymorphic operations to the types (classes) for which the behaviour varies.

Corollary: avoid testing the type of an object as part of conditional logic to perform varying alternatives based on type (class).

Guideline: unless there is a default behaviour in the superclass, declare a polymorphic operation in the superclass to be abstract.

Guideline: when should you consider using an interface?

Benefits:

Contraindications:

Pure Fabrication

Problem: what object should have a responsibility, where you don’t want to violate high cohesion/low coupling, etc., but guidance from Expert etc. is not appropriate?

Solution: assign a highly cohesive set of responsibilities to an artificial/convenience class that doesn’t exist in the problem domain.

Benefits:

Contraindications:

Indirection

Problem:

Solution:

Benefits:

Contraindications:

Protected Variations

Problem: How to design objects/systems so that variation in these elements doesn’t impact other elements?

Solution:

Benefits:

Contraindications:

Guidance:

Liskov Substitution Principle

Don’t talk to strangers

Avoid creating designs that traverse long object structure paths and/or send messages to distant, indirect (stranger) objects. doing so makes designs fragile with respect to changes in object structures.

Within a method, messages should only be passed to:

  1. this object (self)
  2. parameter of the method
  3. attribute of this, (or element of collection that is an attribute of this)
  4. object created in the method

Intent:: avoid coupling between client and knowledge of indirect objects, and connections between objects.

public void doX() {
    // avoid this
    F someF = foo.getA().getB().getC().getD().getE().getF();
    // this is better
    F someF = foo.getFfromFoo();
}

Guideline: The farther along a path one traverses, the more fragile it will be. Instead add a public operation to direct objects that hides how the information is obtained.


Edit this page.