BTS430 Systems Analysis and Design using UML

Design Patterns

Patterns

“…a pattern is a named problem/solution pair that can be applied in new contexts, with advice on how to apply it in novel situations and discussion of its trade-offs.” *

*Larman, page 218

Design Patterns

“The best way to use patterns is to load your brain with them and then recognize places in your design and existing applications where you can apply them. Instead of code reuse, with patterns you get experience reuse.”*

*Head First Design Patterns, p. xi

References for Pattern theory

The “Bible” Design Patterns, Elements of Reusable

Object-Oriented Software Erich Gamma Richard Helm Ralph Johnson John Vlissides

Authors known as the Gang of Four so the patterns are called the GoF patterns

First book – 1995 Most complete

References for Pattern theory

Head First Design Patterns Eric Freeman and Elisabeth Freeman (“must have” for BTS530 and 630)

Applying UML and Patterns, third edition Craig Larman

Beginnings of Patterns

Started with Christopher Alexander, a Professor of Architecture at Berkeley. Invented patterns for building living

architectures, e.g., houses, towns, cities Books: The Timeless Way of Building and A

Pattern Language Direct analogies between creating “living

architecture” and flexible, extensible software*

*Head First Design Patterns, p. 602

GRASP Patterns

“A learning aid to help you understand essential object design and apply design reasoning in a methodical, rational, explainable way”. *

Patterns of assigning object responsibilities

*Larman, p. 277

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

Larman, p. 222

GRASP Patterns

Do not state new ideas Name and codify widely used basic

principles*

*Larman, p. 279

Responsibilities

UML defines a responsibility as “a contract or obligation of a classifier”.

A class embodies a set of responsibilities that define the behaviour of the objects in the class.

Responsibilities

“A responsibility is not the same thing as a method, but methods are implemented to fulfill responsibilities.”

“Responsibilities are implemented using methods that either act alone or collaborate with other methods and objects.”

Larman, p. 217

Fig. 17.2: Responsibilities and methods are related

: Register : Sale

makePayment(cashTendered)

makePayment(cashTendered)

: Paymentcreate(cashTendered)

Implies Sale objects have a responsibilityTo create Payments

Responsibilities revolve around

Doing Knowing Collaboration

“Doing” responsibilities

Doing something itself, such as creating an object or doing a calculation

Initiating action in other objects Controlling and co-coordinating activities

in other objects

Larman, p. 216

“Knowing” responsibilities

Knowing about private encapsulated data Knowing about related objects Knowing about things that it can derive or

calculate

Larman, p. 216

GRASP Patterns

Key three: Creator Controller Information Expert

Creator

Who should be responsible for creating an new instance of some class?

Some options: Assign B the responsibility to create A if one or

more of the following is/are true: B “contains” A (e.g. Invoice creates

InvoiceLineItem) B records A B closely uses A B has the initializing data for A that will be

passed to A when it is created (thus B is the Expert with respect to creating A). (e.g. Sale creates Payment)

p. 291

Creating a SalesLineItem

: Register : Sale : SalesLineItem

makeLineItem(quantity)

create(quantity)

Controller

What first object beyond the UI layer receives and coordinates a system operation? Use Case or Session Controller

Use case/session (e.g. Register)*

Larman, p. 286 and 302

Guidelines/Issues

Controller usually delegates work to other objects—it controls, coordinates, it does not do much work itself

Danger: Bloated controller a single controller receives all system events (and

there are many) a controller that does the work itself a controller that has many attributes; maintains

significant information Among Cures for Bloat

more controllers, use case controllers, more delegation

Information Expert

What is the general principle of assigning responsibilities to objects?

A Solution: Assign a responsibility to the class that

has the information necessary to fulfill it—the “information expert”

(note: start this process by clearly stating the responsibility!)

Larman, p. 294

Information Expert

Example: Sale has the responsibility of knowing its total, expressed with the method named getTotal

Larman, p. 222

Information Expert

: Register : Sale : SalesLineItem

: ProductDescription

getTotal( )

getSubtotal( )

getPrice( )

p. 222

Collaboration

Fulfillment of a responsibility often requires information from different classes of objects

Example, sales total requires the collaboration of 3 classes of objects: Sale, SalesLineItem, ProductDescription

Interact via messages*

*Larman, p. 297

Facade

Hides all of the complexity of one or more classes in a simple interface*

Provides a simplified interface to a subsystem while still exposing the full functionality of the system to those who may need it*

*Head First Design Patterns, p. 254*Head First Design Patterns, p. 260

Database Facade

: control or handler

: data1 : data2 : DBFacade : Database