GRASP

GRASP stands for General Responsibility Assignment Software Patterns. It is a set of nine named patterns for object-oriented design, introduced by Craig Larman in Applying UML and Patterns (1997). The patterns answer a single, recurring question: given an object-oriented design, which class or object should be responsible for a given task or piece of knowledge?

Responsibility assignment is the everyday act of deciding where behavior and data live. Every method, every attribute, every collaboration is the result of some such decision, and small poor choices accumulate into a design that is hard to reason about and hard to change. GRASP gives names to the heuristics experienced designers apply intuitively, so that the reasoning can be made explicit, taught, and debated.

Patterns and principles

GRASP sits between design patterns and design principles. Like the Gang of Four patterns, each GRASP pattern names a recurring solution to a recurring problem. But the GRASP patterns are more general and less prescriptive about structure: they describe which kind of object should own a responsibility, not a particular class hierarchy or collaboration shape. Like design principles, they express preferences – for low coupling and high cohesion – but they are framed as assignable responsibilities rather than as abstract maxims.

The nine patterns

Larman organized GRASP into nine patterns. Five describe specific assignments of responsibility, and the remaining four are evaluative principles applied alongside them.

  • Information expert. Assign a responsibility to the class that has the information needed to fulfill it. This is the most basic heuristic: put behavior where the data already lives, so that the design stays cohesive and collaborators need not exchange data they would otherwise keep private.
  • Creator. Assign responsibility for creating an object to the class that owns it, aggregates it, contains it, records it, or closely uses it. This localizes construction and keeps creation near the lifecycle that gives the object its meaning.
  • Controller. Assign responsibility for receiving and coordinating a system operation to a controller object – typically a use-case controller rather than a single "god" facade. The controller is the first object beyond the UI layer that handles an incoming request, delegating work to other objects rather than doing it itself.
  • Low coupling. Assign responsibilities so that coupling stays low, as an evaluative principle applied to the other choices. The aim is the same one described under coupling: keep dependencies weak, narrow, and visible at a stable interface.
  • High cohesion. Assign responsibilities so that cohesion stays high, again as an evaluative principle. A class with closely related responsibilities is easier to understand, test, and change. See cohesion.
  • Polymorphism. When behavior varies by type, assign responsibility for the variation to polymorphic operations on a type hierarchy, rather than conditionals that test on type. See polymorphism.
  • Pure fabrication. Where assigning responsibility to an information expert would harm cohesion or coupling, invent a class that does not correspond to a domain concept – a fabrication, such as a repository or a service – purely to keep the design clean. It is a deliberate escape hatch from the information expert heuristic.
  • Indirection. Assign responsibility to an intermediary object so that two other components do not have to know about each other directly. The intermediary decouples them, at the cost of an extra hop. Many design patterns – adapter, facade, mediator – are specializations of indirection.
  • Protected variations. Assign responsibility so that variations and instabilities are isolated behind a stable interface, protecting the parts of the design that should not change. Encapsulation and dependency inversion are mechanisms for the same end.

Relation to other heuristics

GRASP does not stand alone. Low coupling and high cohesion are the classical goals of structured design, restated in object-oriented terms. Polymorphism and protected variations overlap with the SOLID principles – notably dependency inversion and the open-closed principle. The Law of Demeter is a complementary heuristic: it constrains how an object talks to its collaborators, where GRASP constrains which object owns the responsibility in the first place.

Because the GRASP patterns are heuristics, they sometimes pull in different directions. Information expert would put a responsibility on the class that holds the data, but that may harm cohesion – in which case pure fabrication offers an alternative. The patterns are tools for reasoning about a trade-off, not rules that resolve it automatically.

See also

References

  • Larman, C. (2004). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd ed.). Prentice Hall.