In Applying UML and Patterns, Craig Larman describes the GRASP Patterns.
GRASP is an acronym that stands for General Responsibility Assignment Software Patterns. The name was chosen to suggest the importance of grasping these principles to successfully design object-oriented software.
Start assigning responsibilities by clearly stating the responsibilities.
To me this says that the object that owns the data should also be the one to operate on the data.
Assign class B the responsibility to create an instance of class A if one or more of the following is true: * B aggregates A objects. * B contains A objects. * B records instances of A objects. * B closely uses A objects. * B has the initializing data that will be passed to A when it is created (thus B is an Expert with respect to creating A).
This pattern is very closely related to the Aggregate Root and Factory pattern.
Cohesion (or more specifically, functional cohesion) is a measure of how strongly related and focused the responsibilities of an element are. An element with highly related responsibilities, and which does not do a tremendous amount of work, has high cohesion. These elements include classes, subsystems, and so on.
A class with low cohesion does many unrelated things, or does too much work. Such classes are undesirable; they suffer from the following problems:
- hard to comprehend
- hard to reuse
- hard to maintain
- delicate; constantly effected by change
Low cohesion classes often represent a very “large grain” of abstraction, or have taken on responsibilities that should have been delegated to other objects.
Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements. As element with low (or weak) coupling is not dependent on too many other elements;
A class with high (or strong) coupling relies on many other classes. Such classes may be undesirable; some suffer from the following problems; * Changes in related classes force local changes. * Harder to understand in isolation. * Harder to reuse because its use requires the additional presence of the classes on which it is dependent.
A Controller is a non-user interface object responsible for receiving or handling a system event. A Controller defines the method for the system operation.