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
- Bloated controllers increases coupling as well. Hence, split when necessary.
- Find the balance between coupling and cohesion.
- 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.