GRASP Patterns

GRASP stands for General Responsibility Assignment Software Patterns (or sometimes Principles). It is used in object oriented design, and gives guidelines for assigning responsibility to classes and objects...

Larman claims that GRASP can be used as a methodical approach to learning basic object design. These are patterns of assigning responsibilities. He also says that there are two types of responsibilities:

knowing responsibilities that include knowing about private encapsulated data, about related objects, and things it can derive or calculate

doing responsibilities include doing something itself, like creating another object or doing a calculation, initiating action in other objects, and controlling and coordinating activities in other objects.

The full set of GRASP patterns are:
Information Expert
Creator
Controller
Low Coupling
High Cohesion
Polymorphism
Pure Fabrication
Indirection
Protected Variations

Information Expert

The Information Expert pattern provides the general principles associated with the assignment of responsibilities to objects. The information expert pattern states that responsibility should be assigned to the information expert—the class that has all the essential information. Systems which appropriately utilize the information expert pattern are easier to understand, maintain and expand as well as increase the possibility that an element can be reused in future development.

Related patterns are
Low Coupling/High Cohesion : The Expert pattern promotes low coupling by putting methods in the classes that have the information that the methods need. Classes whose methods only need the class’ own information have less need to rely on other classes. A set of methods that all operate on the same information tends to be cohesive.

Creator

The Creator pattern solves the problem of who should be responsible for the creation of a new instance of a class. The creator pattern is important because creation of objects is one of the most ubiquitous activities in an object-oriented system. A system that effectively utilizes the creator pattern can also support low coupling, increased understandability, encapsulation and the likelihood that the object in question will be capable of sustaining reuse. Given two classes, class B and Class A, class B should be responsible for the creation of A if class B contains or compositely aggregates, records, closely uses or contains the initializing information for class A. It could then be stated that B is natural object to be a creator of A objects.

The Factory pattern is a common alternative to Creator when there are special considerations, such as complex creation logic. This is achieved by creating a Pure Fabrication object (see below), called Factory that handles the creation.

Controller

The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represent the overall system or a use case scenario. A use case controller should be used to deal with all system events of a use case, and may be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate use case controllers). It is defined as the first object beyond the UI layer that receives and coordinates ("controls") a system operation. The controller should delegate to other objects the work that needs to be done; it coordinates or controls the activity. It should not do much work itself. The GRASP Controller can be thought of as being a part of the Application/Service layer (assuming that the application has made an explicit distinction between the App/Service layer and the Domain layer) in an object-oriented system with common layers.

Related patterns are
Pure Fabrication: The Controller pattern is a specialized form of the Pure Fabrication pattern.
Mediator: The Mediator pattern is used to coordinates events from a GUI. Like controller objects, a highly coupled and incohesive mediator object may involve less overall complexity than an arrangement that distributes the same responsibilities over more objects.

Low Coupling

Low Coupling is an evaluative pattern, which dictates how to assign responsibilities to support:
low dependency between classes;
low impact in a class of changes in other classes;
high reuse potential;

Related patterns are
Interface: One form of coupling between classes is the coupling between a subclass and its superclass. It is often possible to avoid subclassing by using the Interface pattern.
Mediator: It is not necessary or even always desirable for all of the classes in a design to have low coupling and high cohesion. Sometimes the overall complexity of a class can be reduced by concentrating complexity in one class. The Mediator pattern provides an example of that.
Composed Method: It is possible for methods to be uncohesive and difficult to work with. Some common causes are excessive length or too many execution paths within a method. The Composed Method pattern provides guidance of breaking up such methods into smaller, simpler and more cohesive methods.

High Cohesion

High Cohesion is an evaluative pattern that attempts to keep objects appropriately focused, manageable and understandable. High cohesion is generally used in support of Low Coupling. High cohesion means that the responsibilities of a given element are strongly related and highly focused. Breaking programs into classes and subsystems is an example of activities that increase the cohesive properties of a system. Alternatively, low cohesion is a situation in which a given element has too many unrelated responsibilities. Elements with low cohesion often suffer from being hard to comprehend, hard to reuse, hard to maintain and adverse to change.

Related patterns same as related patterns for Low Coupling

Polymorphism

According to the Polymorphism pattern, responsibility of defining the variation of behaviors based on type is assigned to the types for which this variation happens. This is achieved using polymorphic operations.

Related patterns are
Dynamic Linkage You can implement plug-ins or pluggable software components using a combination of polymorphism and the Dynamic Linkage pattern.

Pure Fabrication

A pure fabrication is a class that does not represent a concept in the problem domain, specially made up to achieve low coupling, high cohesion, and the reuse potential thereof derived (when a solution presented by the Information Expert pattern does not). This kind of class is called "Service" in Domain-driven design.

Related patterns are
Low Coupling/High Cohesion The point of the Pure Fabrication pattern is to maintain the low coupling and high cohesion of the classes in an object oriented design.

Indirection

The Indirection pattern supports low coupling (and reuse potential) between two elements by assigning the responsibility of mediation between them to an intermediate object. An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern.

Related patterns are
Low Coupling/High Cohesion: The fundamental motivation for the Don’t Talk to Strangers pattern is to maintain low coupling.
Pure Fabrication: There are sometimes good reasons for calls made to classes added to a design using the Pure Fabrication pattern to violate the guidelines of the Don’t Talk to Strangers pattern.
Mediator: The Mediator pattern provides an example of a class created through pure fabrication that receives direct method calls from classes unrelated to it with a benefit that outweighs the disadvantages of the direct calls.

Protected Variations
The Protected Variations pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an interface and using polymorphism to create various implementations of this interface.

"The critical design tool for software development is a mind well educated in design principles. It is not the UML or any other technology" (Larman, Craig. Applying UML and Patterns - Third Edition). Thus, GRASP is really a mental toolset, a learning aid to help in the design of object oriented software.