COMPUTING SCIENCE 220
Software Engineering and Human-Computer Interfaces

GRASP: Designing Objects with Responsibilities

Responsibilities

responsibility

a contract or obligation of a classifier

Responsibilities are assigned to classes of objects during object design.

• knowing
• doing

Responsibility assignment decisions are reflected in interaction diagrams:

Patterns

pattern

a named description of a problem and solution that can be applied to new contexts

• naming as a form of abstraction ("chunking")
• repertoire of general principles and idiomatic solutions
• codified in a structured format
  • name
  • context/problem
  • solution
  • example
  • discussion
  • contraindications
  • benefits
  • related patterns or principles

GRASP: fundamental principles of object design and responsibility assignment, expressed as patterns.

The Information Expert Pattern

Figure 16.3 Partial domain model

Figure 16.4 Partial interaction and class diagrams

Figure 16.5 Sales accumulates subtotals calculated by SalesLineItems

Figure 16.6 SalesLineItems get price from ProductSpecification

Important Software Design Patterns (Principles)

Separation of concerns

design for a separation of major system concerns

• layered architecture (see Fig. 30.1, p. 451)
• aspect-oriented programming for cross-cutting concerns (see pp. 498-499)

Low coupling

coupling

how strongly one element is connected to, has knowledge of, or relies on other elements

High cohesion

cohesion

how strongly related and focused the responsibilities of an element are

Modular design

modularity

the property of a system that has been decomposed into a set of cohesive and loosely coupled modules [Booch]

See Characteristics of High-Quality Routines, based on Chapter 5 of Steve McConnell's Code Complete, for a list of the seven levels of cohesion, criteria by which we can evaluate the degree of coupling between routines, and a list of five levels of coupling.

Low coupling/high cohesion example

Figure 16.9 Register creates Payment

Figure 16.10 Sale creates Payment

The Creator Pattern

Assign class B the responsibility of creating an instance of class A if:

1. B aggregates A objects.
2. B contains A objects.
3. B records instances of A objects.
4. B closely uses A objects.
5. B has the initializaing data that will be passed to the A object when it is created.

aggregation

A kind of association used to model whole-part relationships between things.

Figure 16.7 Partial domain model.

Figure 16.8 Creating a SalesLineItem

The Controller Pattern

Assign the responsibility for receiving or handling a system event message to a class that:

1. Represents the overall system, device, or subsystem.
2. Represents a use case scenario in which the system event occurs.

system event

An event generated by an external actor.

system operation

An operation of the system in response to a system event.

controller

A non-user interface object responsible for receiving or handling a system event, and that defines the method for the system operation.

Figure 16.13 System operations associated with the system events.

Figure 16.14 Controller for enterItem?

Figure 16.15 Controller choices.

Figure 16.16 Allocation of system operations.

Figure 16.17 Desirable coupling of interface layer to domain layer.

Figure 16.18 Less desirable coupling of interface layer to domain layer.