Copy Of Copy Of Patterns

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 tradeoffs.” *

*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

makePayment

(cashTendered

: Sale

) makePayment

(cashTendered

) create (cashTendered

Implies Sale objects have a responsibility To create Payments

)

: Payment

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

: Sales LineItem

: 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