Content deleted Content added
m unpiped links using script |
|||
| (46 intermediate revisions by 25 users not shown) | |||
Line 3:
{{primary|date=May 2015}}
'''General Responsibility Assignment Software Patterns''' (or '''Principles'''), abbreviated '''GRASP''',
The different patterns and principles used in GRASP are controller, creator, indirection, information expert, low [[coupling (computer science)|coupling]], high [[cohesion (computer science)|cohesion]],
== Patterns ==▼
In OO 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. ▼
▲In
===Information expert===
Line 23 ⟶ 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"/>{{
'''Related Pattern or Principle''': Low Coupling, High Cohesion
===Creator===
Line 29 ⟶ 30:
The 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.
Problem: Who creates object <code>A</code>?<br>
Solution: In general, Assign class <code>B</code> the responsibility to create object <code>A</code> if one, or preferably more, of the following apply:
* Instances of <code>B</code> contain or compositely aggregate instances of <code>A</code>
* 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"/>{{rp|16:16.7}}
'''Related Pattern or Principle''': Low Coupling, [[Factory pattern]]
=== Controller ===
Line 42 ⟶ 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
'''Related Pattern or Principle''': [[Command_pattern|Command]], [[Facade_pattern|Facade]], [[Layer_(object-oriented_design)|Layers]], Pure Fabrication
===Indirection===
The indirection pattern supports low coupling and
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>
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 54 ⟶ 62:
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 responsibilities for the following benefits:
* lower dependency between the classes,
* change in one class having a lower impact on other classes,
* higher reuse potential.
===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
===Polymorphism===
{{main|Polymorphism in object-oriented programming}}
According to the '''polymorphism''' principle, responsibility for defining the variation of behaviors based on type is assigned to the type for which this variation happens. This is achieved using [[Polymorphism (computer science)|polymorphic]] operations. The user of the type should use polymorphic operations instead of explicit branching based on type.
Problem: How to handle alternatives based on type? How to create pluggable software components?<br>
Solution: When related alternatives or behaviors vary by type (class), assign responsibility for the behavior—using polymorphic operations—to the types for which the behavior varies. (Polymorphism has several related meanings. In this context, it means "giving the same name to services in different objects".)
===Protected variations===
{{see also|Open/closed principle}}
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 do 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 thereof 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'''
• Low Coupling.
• High Cohesion.
==See also==
* [[Anemic ___domain model]]
* [[Design pattern (computer science)]]
* [[Design Patterns (book)|''Design Patterns'' (book)]]
* [[SOLID (object-oriented design)]]
==References==
<references>
<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>
<ref name="Larman2004">{{cite book |author=[[Craig Larman]] |title=Applying UML and Patterns
<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>
[[Category:Software design]]
[[Category:Programming principles]]
| |||