GRASP Cheat Sheet by asminog

What is a basic principle by which to assign respon­sib­ilities to objects?
Assign respon­sib­ility to the class that has the inform­ation needed to fulfill it.

Inform­ation expert (also expert or the expert principle) is a principle used to determine where to delegate respon­sib­ilities such as methods, computed fields, and so on.

This will lead to placing the respon­sib­ility on the class with the most inform­ation required to fulfill it.

Who creates object A?
In general, Assign class B the respon­sib­ility to create object A if one, or preferably more, of the following apply:
B contain or compos­itely aggregate instances of A
B record instances of A
B closely use instances of A
B have the initia­lizing inform­ation for instances of A and pass it on creation.

How to design objects, subsys­tems, and systems so that the variations or instab­ility in these elements does not have an undesi­rable impact on other elements?

Identify points of predicted variation or instab­ility; assign respon­sib­ilities to create a stable interface around them.

High cohesion is an evaluative pattern that attempts to keep objects approp­riately focused, manageable and unders­tan­dable. High cohesion is generally used in support of low coupling. High cohesion means that the respon­sib­ilities of a given set of elements are strongly related and highly focused on a rather specific topic. Breaking programs into classes and subsys­tems, if correctly done, is an example of activities that increase the cohesive properties of named classes and subsys­tems. Altern­ati­vely, low cohesion is a situation in which a set of elements, of e.g., a subsystem, has too many unrelated respon­sib­ili­ties. Subsystems with low cohesion between their consti­tuent elements often suffer from being hard to compre­hend, reuse, maintain and change as a whole.

Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements. Low coupling is an evaluative pattern that dictates how to assign respon­sib­ilities for the following benefits:

lower dependency between the classes,
change in one class having a lower impact on other classes,
higher reuse potential.

A pure fabric­ation 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 inform­ation expert pattern does not). This kind of class is called a "­ser­vic­e" in domain­-driven design.

How to handle altern­atives based on type? How to create pluggable software compon­ents?

When related altern­atives or behaviors vary by type (class), assign respon­sib­ility for the behavi­or—­using polymo­rphic operat­ions—to the types for which the behavior varies. (Polym­orphism has several related meanings. In this context, it means "­giving the same name to services in different object­s".)

Who should be respon­sible for handling an input system event?

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 the use cases Create User and Delete User, one can have a single class called UserCo­ntr­oller, instead of two separate use case contro­llers.

Where to assign respon­sib­ility, to avoid direct coupling between two (or more) things? How to de-couple objects so that low coupling is supported and reuse potential remains higher?

Assign the respon­sib­ility to an interm­ediate object to mediate between other components or services so that they are not directly coupled.
The interm­ediary creates an indire­ction between the other compon­ents.