Content deleted Content added
adding the missing option of a "facade controller" (see Larman) |
m unpiped links using script |
||
| (7 intermediate revisions by 7 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]]
[[Craig Larman|Larman]] states that "the critical design tool for software development is a mind well educated in design principles. It is not [[
==Patterns==
Line 45:
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 80 ⟶ 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
Solution: Identify points of predicted variation or instability; assign responsibilities to create a stable interface around them.
| |||