GRASP (object-oriented design)
Lua error in package.lua at line 80: module 'strict' not found. Lua error in package.lua at line 80: module 'strict' not found.
General Responsibility Assignment Software Patterns (or Principles), abbreviated GRASP, consist of guidelines for assigning responsibility to classes and objects in object-oriented design.
The different patterns and principles used in GRASP are: Controller, Creator, Indirection, Information Expert, High Cohesion, Low Coupling, Polymorphism, Protected Variations, and Pure Fabrication. All these patterns answer some software problem, and these problems are common to almost every software development project. These techniques have not been invented to create new ways of working, but to better document and standardize old, tried-and-tested programming principles in object-oriented design.
Computer scientist Craig Larman states that "the critical design tool for software development is a mind well educated in design principles. It is not the UML or any other technology."[1] Thus, GRASP are really a mental toolset, a learning aid to help in the design of object-oriented software.
Contents
Patterns
Controller
The Controller pattern assigns the responsibility of dealing with system events to a non-UI class that represents the overall system or a use case scenario. A Controller object is a non-user interface object responsible for receiving or handling a 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 use cases Create User and Delete User, one can have a single 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 the work that needs to be done to other objects; 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 [2] (assuming that the application has made an explicit distinction between the application/service layer and the domain layer) in an object-oriented system with Common layers in an information system logical architecture.
Creator
<templatestyles src="Module:Hatnote/styles.css"></templatestyles>
Creation of objects is one of the most common activities in an object-oriented system. Which class is responsible for creating objects is a fundamental property of the relationship between objects of particular classes.
In general, a class B
should be responsible for creating instances of class A
if one, or preferably more, of the following apply:
- Instances of
B
contain or compositely aggregate instances ofA
- Instances of
B
record instances ofA
- Instances of
B
closely use instances ofA
- Instances of
B
have the initializing information for instances ofA
and pass it on creation.
High Cohesion
<templatestyles src="Module:Hatnote/styles.css"></templatestyles>
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 averse to change.[3]
Indirection
<templatestyles src="Module:Hatnote/styles.css"></templatestyles>
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.
Information Expert
<templatestyles src="Module:Hatnote/styles.css"></templatestyles>
Information Expert (also Expert or the Expert Principle) is a principle used to determine where to delegate responsibilities. These responsibilities include methods, computed fields, and so on.
Using the principle of Information Expert, a general approach to assigning responsibilities is to look at a given responsibility, determine the information needed to fulfill it, and then determine where that information is stored.
Information Expert will lead to placing the responsibility on the class with the most information required to fulfill it.[4]
Low Coupling
<templatestyles src="Module:Hatnote/styles.css"></templatestyles>
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, which dictates how to assign responsibilities to support:
- lower dependency between the classes,
- change in one class having lower impact on other classes,
- higher reuse potential.
Polymorphism
<templatestyles src="Module:Hatnote/styles.css"></templatestyles>
According to Polymorphism, 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.
Protected Variations
<templatestyles src="Module:Hatnote/styles.css"></templatestyles>
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.
Pure Fabrication
<templatestyles src="Module:Hatnote/styles.css"></templatestyles>
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.
See also
- Anemic Domain Model
- Design pattern (computer science)
- Design Patterns (book)
- SOLID (object-oriented design)
Notes
- ↑ Larman 2005, p. 272.
- ↑ Lua error in package.lua at line 80: module 'strict' not found.
- ↑ Larman 2005, pp. 314–315.
- ↑ Larman 2005 chapter 17, section 11.
References
- Lua error in package.lua at line 80: module 'strict' not found.