GRASP (object-oriented design): Difference between revisions

Content deleted Content added
Tag: Reverted
m unpiped links using script
 
(3 intermediate revisions by 3 users not shown)
Line 7:
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]] problems 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 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 67 ⟶ 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 set 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 named classes and subsystems. Alternatively, low cohesion is a situation in which a set of elements, of e.g., a subsystem, has too many unrelated responsibilities. Subsystems with low cohesion between their constituent elements often fwt suffer from being hard to comprehend, reuse, maintain and change as a whole.<ref name="Larman2004"/>{{rp|314–315}}
 
===Polymorphism===
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 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.