GRASP (object-oriented design): Difference between revisions

Revision as of 18:03, 25 February 2021

Revision as of 18:30, 25 February 2021

Line 3:

{{primary|date=May 2015}}

'''General Responsibility Assignment Software Patterns''' (or '''Principles'''), abbreviated '''GRASP''', consistis ofa guidelinesset forof assigning"nine responsibilityfundamental to classes and objectsprinciples in [[object-oriented design|object design]].<ref>https://dzone.com/articles/solid-grasp- and-other-basic-principles-of-object-o 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 answersolve some [[software]] problems, and these problems areproblem common to almost everymany [[software development]] projectprojects. 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.

Computer scientist [[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"/>{{sfn|Larman|2005rp|p = 272}} Thus, the GRASP principles are really a mental toolset, a learning aid to help in the design of object-oriented software.

== Patterns ==

In OO (Object Oriented)object-oriented design, a pattern is a named description of a problem and solution that can be applied in new contexts; ideally, a pattern advises us on how to apply its solution in varying circumstances and considers the forces and trade-offs. Many patterns, given a specific category of problem, guide the assignment of responsibilities to objects.

===Information expert===

Line 22:

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.

This will lead to placing the responsibility on the class with the most information required to fulfill it.<ref name="Larman2004"/>{{Harvnbrp|Larman|200517:11}} chapter 17, section 11.</ref>

'''Related Pattern or Principle''': Low Coupling, High Cohesion

Line 35:

* Instances of <code>B</code> record instances of <code>A</code>

* Instances of <code>B</code> closely use instances of <code>A</code>

* Instances of <code>B</code> have the initializing information for instances of <code>A</code> and pass it on creation.<ref name="Larman2004"/>{{Harvnbrp|Larman|2005}} chapter 16, section :16.7</ref>}}

'''Related Pattern or Principle''': Low Coupling, [[Factory pattern]]

Line 46:

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.

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>{{cite web |url=https://groups.yahoo.com/neo/groups/domaindrivendesign/conversations/messages/7582 |title=Application Layer like business facade? |workname="Yahoo! Groups (domaindrivendesign) |access-date=15 July 2010}}<"/ref> (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.

'''Related Pattern or Principle''': [[Command_pattern|Command]], [[Facade_pattern|Facade]], [[Layer_(object-oriented_design)|Layers]], Pure Fabrication

Line 56:

Solution: Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled. <br>

The intermediary creates an '''indirection''' between the other components.

===Low coupling===

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 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, reuse, maintain and change.<ref name="larman314Larman2004"/>{{Harvnbrp|Larman|2005|pp=314&ndash;315314–315}}.</ref>

===Polymorphism===

Line 93:

* [[Anemic ___domain model]]

* [[Design pattern (computer science)]]

* [[Design Patterns (book)|''Design Patterns'' (book)]]

* [[SOLID (object-oriented design)]]

==Notes==

{{Reflist}}

==References==

<references>

{{refbegin}}

<ref name="Larman2001">{{cite book |author=[[Craig Larman]] |title=Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process |edition=2nd |publisher=Prentice Hall |year=2001 |isbn=0-13-092569-1 |url=https://personal.utdallas.edu/~chung/SP/applying-uml-and-patterns.pdf}}</ref>

*{{cite book

|last=Larman|first=Craig|author-link=Craig Larman

<ref name="Larman2004">{{cite book |author=[[Craig Larman]] |title=Applying UML and Patterns &ndash;: An Introduction to Object-Oriented Analysis and Design and Iterative Development |edition=3rd |publisher=Pearson |year=2004 |isbn=978-0131489066}}</ref>

|orig-year=2004

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

|edition=3rd

|publisher=[[Prentice Hall]]

|year=2005

|isbn=0-13-148906-2

|___location=New Jersey

|url=http://authors.phptr.com/larman/uml_ooad/index.html

}}

{{refend}}

<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}}</ref>

<!-- [[pt:GRASP]] The Portuguese article named 'GRASP' does not refer to this subject. It refers to an algorithm -->

</references>

{{DEFAULTSORT:Grasp (Object Oriented Design)}}

<!-- Categories -->

[[Category:Software design]]

[[Category:Programming principles]]