GRASP (object-oriented design)

This is an old revision of this page, as edited by Chrislk02 (talk | contribs) at 18:02, 21 December 2007 (adding the creator pattern). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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...

Examples of different patterns/principles used in GRASP are: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations. All these patterns answer some software problem, and in almost every case these problems are common to most every software development project, thus they don't exist to facilitate new information but to better document and standardize old, tried-and-true programming principles in object oriented design.

"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. [1]). Thus, GRASP is really just a toolset, a learning aid to help in the design of object oriented software.

Patterns

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 necessary information. Systems which appropriatley utilize the information expert pattern are easier to under, maintain and expand as well as increase the possibilitiy the an element can be reused in future development.[1]

Creator

The Creator pattern solves the problem of who should be responsbile 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 activites in an object-oriented system. A system that effectivly utilizes the creator pattern can also support low coupling, increased understandability, encapsulation and the liklihood that the object in question will be capable of sustaining reuse. Given two classes, class B and Class A, class B should be responsibile for the creation of A if class B contains or compositely aggregates, records, closley uses or contains the initlaizing information for class A. It could then be stated that B is a creator of A objects.[2]


The Creator pattern deals with assigning the responsibility of creating new objects (instances of classes). New instances of class Class should be created by a class such that:

  • it aggregates instances of Class, or;
  • it contains instances of Class, or;
  • it records instances of Class, or;
  • it closely uses instances of Class, or;
  • it has the necessary information for creating the new instance of Class.

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);

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;

Factory

This pattern helps determine who should be responsible for creating objects when there are special considerations, such as complex creation logic. This is achieved by creating a Pure Fabrication object, called Factory that handles the creation.

High Cohesion

High Cohesion is an evaluative pattern that attempts to keep objects appropriatley focused, manageable and understandable. High cohesion is genereally 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 activies that increase the cohesive properties of a system. Alternativley, low cohesion is a situation in which a given element has too many unrelated responsibilites. Elements with low cohesion offer suffer from being hard to comprehend, hard to reuse, hard to maintain and adverse to change.[3]

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.

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).

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.

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.

Works Cited

  • Larman, Craig (2005). Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd ed.). Prentice Hall PTR. ISBN 0-13-148906-2. {{cite book}}: Text "___location Upper Saddle River, New Jersey" ignored (help)

References

  1. ^ (Larman 294)
  2. ^ (Larman 292)
  3. ^ (Larman 314-315)