GRASP / FAÇADE

GRASP stands for general responsibility assignment software pattern. It is actually a low-level design pattern of assigning responsibilities, like reasons about design trade-offs when assigning methods and fields to classes.

GRASP is a learning aids to help one understand essential object design and apply design reasoning in a methodical, rational, explainable way. The design model is known as FAÇADE.

FAÇADE model has a central controller that:

• does not do much work itself
• delegates to other objects

When To Use (Problem)

• When a system is confusingly requires something to coordinate and control all the concepts within.
• System is not big and not many (1 controller is suffice to control entire system).
• System has a lot of high coupling concepts implemented within and is in need to support reusability.

Approach (Solution)

Use a central controller to:

• coordinate the executions
• decouple/isolate concepts (e.g. UI Model away from Data Model)
• support reusability (decoupled concepts can now be developed independently)

Caveats

1. Bloated controllers increases coupling as well. Hence, split when necessary.
2. Find the balance between coupling and cohesion.
3. Use GRASP to balance responsibilities.
   • Assigning a responsibility to a class that has the necessary information to fulfill the responsibility (Information Expert)
   • Start with common intuition or refers to domain model for fitting abstractions

GRASP Approach

GRASP is a way to balance cohesion with coupling by identifying the creator of the concept.

The rules of assignment is that when B creates A, assign class responsibility of instance A to B when any (one or the more the better) of the following applies:

• B aggregates A objects
• B contains A objects
• B records instances of A objects
• B closely uses A objects
• B has the initializing data for creating A objects

This promotes low coupling, high cohesion class creation that promotes evolvability (design for change).

However, sometimes, objects must be created in special ways due to:

• complicated initialization
• instantiate different classes in different circumstances
• when cohesion suggests putting creation into different objects (E.g: builder / factory patterns)

Expected Outcome (Consequences)

• Balance between cohesion and coupling.
• More modular and reusability classes/concepts.
• Clarity.