GRASP Patterns

General Responsibility Assignment Software Patterns or Principles.

From Craig Larman’s brilliant book “Applying UML And Patterns”. Essentially, these are general patterns to assist in responsibility driven design.

GRASP

Information Expert	A general principle of object design and responsibility assignment. Assign a responsibility to the information expert – the class that has the information necessary to fulfill the responsibility.
Creator	Who creates? (Note that Factory is a common alternative solution.) Assign class B the responsibility to create an instance of class A if one of these is true B contains A B aggregates A B has the initializing data for A B records A B closely uses A
Controller	What first object beyond the UI layer receives and coordinates (‘controls’) a system operation? Assign the responsibility to an object representing one of these choices: Represents the overall ‘system’, a ‘root object’, a device that the software is running within, or a major subsystem (these are all variations of a facade controller). Represents a use case scenario within which the system operation occurs (a use-case or session controller)
Low Coupling	How to reduce the impact of change? Assign responsibilities so that (unnecessary) coupling remains low. Use this prinicple to evaluate alternatives.
High Cohesion	How to keep objects focused, understandable, and manageable, and as a side-effect, support Low Coupling? Assign responsibilities so that cohesion remains high. Use this to evaluate alternatives.
Polymorphism	Who is responsible when behavior varies by type? 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.
Pure Fabrication	Who is responsible when you are desperate, and do not want to violate high cohesion and low coupling? Assign a highly cohesive set of responsibilities to an artificial or convenience ‘behavior’ class that does not represent a problem domain concept – something made up, in order to support high cohesion, low coupling, and reuse.
Indirection	How to assign responsibilities to avoid direct coupling? Assign the responsibility to an intermediate object to mediate between other components or services, so that they are not directly coupled.
Protected Variations	How to assign responsibilities to objects so that the variations or instability in these elements do not have an undesirable impact on other elements? Identify points of predicted variation or instability; assign responsibilites to create a stable ‘interface’ around them.

Class Diagram Summary

Every now and then I’m tasked to do something which requires me to quickly jog my memory. This time it was a class diagram, and Martin Fowler’s Uml Distilled is such an excellent resource that I’ve decided to list some of the important points it raises here. I’ve added a few of my own notes where appropriate, I hope you may find them useful. I strongly encourage you to purchase Martin Fowler’s book, it’s an invaluable resource.

Martin Fowler’s website: http://martinfowler.com/

For more information on class diagrams see wikipedia

Class Diagrams

A class diagram describes the types of objects in the system and the various kinds of static relationships that exist among them. Class diagrams also show the properties and operations of a class and the constraints that apply to the way objects are connected. The UML uses the term “feature” as a general term that covers properties and operations of a class. The boxes which represent a class are divided into three compartments:

1. The name of the class (in bold)
2. Its attributes
3. Its operations

Hint: The biggest danger with class diagrams is that you can focus exclusively on structure and ignore behavior. Therefore, do them in conjunction with some form of behavioral technique.

Properties

Properties represent structual features of a class as either an attribute or association. Typically, attributes are used for simple properties whilst associations are used for more complex types.

Hint: The choice is more about emphasis.

Attributes

visibility name: type multiplicity = default {property-string}

- name: String[1] = “Untitled” {readonly}

Hint: visibility is either + (public), - (private), # (protected)

Associations

An association is a solid line between two classes, directed from the source class to the target class. The name of the property goes at the target end of the association, along with the multiplicity. The target end is the type of the property.

Associations can show multiplicity at both ends of the line.

Multiplicity

The multiplicity of a property is an indication of how many objects may fill the property. Typically:

• 1 (An order must have exactly one customer)
• 0..1 (A corporate customer may or may not have a single sales rep.)
• * (A customer need not place an Order and there is no upper limit – zero or more)

If the lower and upper bounds are the same, you can use one number. * is short for 0..*

The default multiplicity for an attribute is 1.

Various terms for multiplicity:

• Optional implies a lower bound of 0
• Mandatory implies a lower bound if 1 or possibly more
• Single-valued implies an upper bound of 1
• Multivalued implied an upper bound of more than 1: usually *

Hint: For a mulitvalued property, use a plural form for its name.

It is assumed the elements in a multivalued multiplicity form a set, in no particular order. Terms can be added to the association end to provide more clarity, for example:

{ordered}
{unordered}
{unique}
{nonunique}
{bag}

Hint: Object oriented design is about providing objects that are able to do rich behavior. If you are making repeated calls for data by using accessors, that’s a sign that some behavior should be moved to the object that has the data. Craig Larman advises the same thing, see the Information Expert GRASP pattern. Also worth keeping in mind, pay attention to semantics, if you can’t name the class succintly then it has too many responsibilities.

Bidirectional Associations

A bidirectional association is a pair of properties that are linked together as inverses, ie. The Car class, owner:Person[1], and the Person class cars:Car[*]. Bidirectional associations have navigability arrows at both ends.

When implementing a bidirectional association let the single-valued side control the relationship. This means the slave end needs to leak the encapsulation of its data to the master end.

Operations

visibility name (parameter-list) : return-type {property-string}

The parameters are notated in a similar way to attributes:

direction name: type = default value

+ balanceOn (date: Date) : Money

The direction indicates whether the parameter is input (in), output (out), or both (inout).

Operations are the actions that a class knows how to carry out, typically implemented as methods in code.

With conceptual models, use operations to indicate the prinicipal responsibilities of that class, perhaps using a couple of words summarizing a CRC responsibility.

If the operation does not modify the observable state (what can be perceived from the outside), then include the propery-string {query}. Try to write operations so that modifiers do not return a value, this is referred to as the Command-Query seperation principle.

Hint: A subtle distinction is the difference between an operation and a method. An operation is something that is invoked on an object, the procedure declaration, where as a method is the body of a procedure.

Generalization

In OO languages this is known as inheritance.

Everything we say about the superclass is true also for the subclass.

Hint: An important principle of using inheritance effectively is substitutability.

Dependency

A dependency exists between two elements if changes to the definintion of one element (the supplier or target) may cause changes to the other (the client or source).

You can add a keyword to a dependency to add more details of the relationship:

<<call>>	The source calls an operation in the target
<<create>>	The source creates instances of the target
<<derive>>	The source is derived from the target
<<instantiate>>	The source is an instance of the target
<<permit>>	The target allows the source to access the target’s private features
<<realize>>	The source is an implementation of a specification or interface defined by the target
<<refine>>	Refinement indicates a relationship between different semantic levels
<<substitute>>	The source is substitutable for the target
<<trace>>	Used to track such things as requirements to classes
<<use>>	The source requires the target for its implementation

You should keep dependencies to a minimum.

Hint: To understand and control dependencies, use them with a package diagram.