GRASP (object-oriented design): Difference between revisions

Revision as of 12:14, 28 September 2021

Latest revision as of 05:16, 1 July 2024

(15 intermediate revisions by 15 users not shown)

Line 5:

'''General Responsibility Assignment Software Patterns''' (or '''Principles'''), abbreviated '''GRASP''', is a set of "nine fundamental principles in [[object-oriented design|object design]] and responsibility assignment"<ref name="Larman2001"/>{{rp|6}} first published by [[Craig Larman]] in his 1997{{cn|date=February 2021}} book ''Applying UML and Patterns''.

The different patterns and principles used in GRASP are controller, creator, indirection, information expert, low [[coupling (computer science)|coupling]], high [[cohesion (computer science)|cohesion]], [[Polymorphism (object-oriented programming)|polymorphism]], protected variations, and pure fabrication.<ref name="Umair2018"/> All these patterns solve some [[software]] problemproblems common to many [[software development]] projects. These techniques have not been invented to create new ways of working, but to better document and standardize old, tried-and-tested [[Computer programming|programming]] principles in object-oriented design.

[[Craig Larman|Larman]] states that "the critical design tool for software development is a mind well educated in design principles. It is not [[Unified Modeling Language|UML]] or any other technology."<ref name="Larman2004"/>{{rp|272}} Thus, the GRASP principles are really a mental toolset, a learning aid to help in the design of object-oriented software.

==Patterns==

Line 44:

Problem: Who should be responsible for handling an input system event?<br>

Solution: 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 ''UserController'', instead of two separate use case controllers. Alternatively a ''facade controller'' would be used; this applies when the object with responsibility for handling the event represents the overall system or a root object.

The controller 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<ref name="Yahoo"/> (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.

Line 51:

===Indirection===

The indirection pattern supports low coupling and reuses 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 control-controller pattern. This ensures that coupling between them remains low.

Problem: Where to assign responsibility, 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? <br>

Line 66:

===High cohesion===

{{main|Cohesion (computer science)}}

'''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 elementset of elements are strongly related and highly focused on a rather specific topic. Breaking programs into classes and subsystems, if correctly done, is an example of activities that increase the cohesive properties of anamed systemclasses and subsystems. Alternatively, low cohesion is a situation in which a givenset elementof elements, of e.g., a subsystem, has too many unrelated responsibilities. ElementsSubsystems with low cohesion between their constituent elements often suffer from being hard to comprehend, reuse, maintain and change as a whole.<ref name="Larman2004"/>{{rp|314–315}}</ref>

===Polymorphism===

Line 79:

The '''protected variations''' pattern protects elements from the variations on other elements (objects, systems, subsystems) by wrapping the focus of instability with an [[Interface (computer science)|interface]] and using [[Polymorphism (computer science)|polymorphism]] to create various implementations of this interface.

Problem: How to design objects, subsystems, and systems so that the variations or instability in these elements doesdo not have an undesirable impact on other elements?<br>

Solution: Identify points of predicted variation or instability; assign responsibilities to create a stable interface around them.

===Pure fabrication===

{{see also|Service (systems architecture)}}

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 there ofthereof derived (when a solution presented by the ''information expert'' pattern does not). This kind of class is called a "service" in [[___domain-driven design]].

'''Related Patterns and Principles'''

Line 104:

<ref name="Umair2018">{{cite web |author=Muhammad Umair |title=SOLID, GRASP, and Other Basic Principles of Object-Oriented Design |website=DZone |date=2018-02-26 |url=https://dzone.com/articles/solid-grasp-and-other-basic-principles-of-object-o}}</ref>

<ref name="Yahoo">{{cite web |url=https://groups.yahoo.com/neo/groups/domaindrivendesign/conversations/messages/7582 |url-status=dead |title=Application Layer like business facade? |work=Yahoo! Groups (domaindrivendesign) |access-date=2010-07-15 |archive-date=2020-08-07 |archive-url=https://web.archive.org/web/20200807182246/https://groups.yahoo.com/neo/groups/domaindrivendesign/conversations/messages/7582 }}</ref>

</references>