UML - Patterns 1

Design Patterns

UML - Patterns 2

Becoming Good OO Developers

• Developing good OO Software is hard• Takes a lot of time to take advantage of all OO

features• Lots of Experience needed to become good

designers• Many systems are not leveraging OO advantages• To master OO software design, study experienced

developers design• Reuse proven software design • => Patterns can help

UML - Patterns 3

Design Tips & Hints (High level Patterns)

• Layering Improves stability, understandability, flexibility Reduces impact to changes Restrict dependencies/coupling between packages/subsystems

• GUI (Boundary Classes) separated in one layer/package

Allow the User Interface to change without impacting the rest of the system

• Package Functionally related Classes Changes in one Class impact the other Class Rich Interaction between Classes

• Package should be cohesive

• Reuse proven software design • => Patterns can help

UML - Patterns 4

Design

UML - Patterns 5

Design• Refine the Class Diagram• Structure system

Subsystems, Interfaces, Classes• Define subsystems dependencies• Capture major interfaces between subsystems• Assign responsibilities to new design classes• Describe realization of Use Cases

Use Sequence and Collaboration Diagrams• Assign visibility to class attributes • Define Methods signature• Develop State diagram for relevant design classes• Use Interaction Diagram to distribute behavior among

classes• Use Design Patterns for parts of the system

UML - Patterns 6

Design Patterns Definition

abstract a recuring design structure common solution to a common problem in a given

context specify structure and behavior of a society of

classes describe ways a cluster of classes work together

to accomplish a goal a way to package and reuse design experience

Advantages Codify existing knowledge about how to use good

design practices Naming a design concept helps understands the

problem/solution Facilitates communication among team members

UML - Patterns 7

Goals of Design Patterns Codify good Design

distill and disseminate experience

aid novices and experts

Give design structures explicit names

common vocabulary

Capture Design information

Improve Documentation

Expose Design Decision

8UML - Patterns 8

Essential Elements of a Pattern

NAME -- a handle for identifying a design problem, its

solution and consequences- increases vocabulary

PROBLEM -

SOLUTION -

CONSEQUENCES -

- places where the pattern is applicable

- the elements that make up the design, their relationships, responsibilities and interactions

- the results and tradeoffs of applying the pattern (pros and cons)

9UML - Patterns 9

Model View Controller Pattern

the archetypal pattern

popularized in Smalltalk systems

is used to build user interfaces

is composed of three kinds of objects -

MODEL - creates application data to be displayed

VIEW - handles the presentation of data

CONTROLLER - defines the user interface’s reaction to user input

serves to decouple views from models

10UML - Patterns 10

MVC Pattern

Window Window Window

a = 50%b = 30%c = 20%

x 60 30 10y 50 30 20z 80 10 10

a b c

a b c

a

b

c

Views

model

11UML - Patterns 11

Elements of a Pattern Description- Pattern Name and Classification

- Intent: short description and purpose

- Also Known As: other names used

- Motivation: motivating scenario demonstrating pattern’s use

- Applicability: circumstances in which pattern applies

- Structure : graphical representation of the pattern using UML

- Participants: classes and objects and their responsibilities

- Collaborations: how participants cooperate

- Consequences: results of applying the pattern, pro and con

- Implementation: language dependent issues such as hints, pitfalls or technique

- Sample Code: sample implementatio

- Known Uses: real systems using it

- Related Patterns: how other patterns relate to it.

UML - Patterns 12

Pattern Example: Observer Intent:

define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically

Applicability: when an object is defined in one way but presented in many ways

when there is a one-to-many dependency to enforce Participants:

Subject: knows its Observers. Any numbers can observe a subject

Observer: defines an interfacefor updating objects

Concrete Subject: stores state of interest, sends notification to observers

Concrete Observer: maintains a ref to ConcreteSubject, stores state of interest, implements updating mechanism to keep states consistent

UML - Patterns 13

Observer Pattern Structure

Concrete Observer

observerState

Concrete Subject

GetState()

Observer

Update()

Subject

Attach(observer)Detach(observer)notify()

observers

subjectState

Update()

subject

*

observerState= subject->GetState()

for all o in observers { o->update()}

return subjectState

UML - Patterns 14

Observer Pattern Interactions

:aConcrete Observer:aConcrete Subject

GetState()

notify()

Update()

:anotherConcrete Observer

setState()

Update()

GetState()

UML - Patterns 15

Pattern Example: Observer Collaborations:

ConcreteSubject notifies its Observers whenever a change occurs

After being informed of a change in the concreteSubject, the concreteObserver querries the subject for information, and updates its state to reconcile it with Subject’s State

Consequences: Subject and Observers may vary independently, only abstract coupling

Can reuse one without the other

Can add Observers without any change Known Uses:

MVC

Interviews

MFC

UML - Patterns 16

Pattern Example: Observer Implementation:

Mapping subjects to their observers

Observing more than one subject

who triggers the update?

dangling references to deleted subjects

Subject State consistency before notification

17UML - Patterns 17

Pattern Classification

Creational - patterns which are concerned with the process of object creation

Structural

Behavioral

- patterns which deal with composition of classes or objects

- patterns which characterize the responsibilities of objects and classes

PURPOSE

SCOPE

Class - patterns which deal with relationships between classes and their subclasses

Object - patterns which deal with relation-ships between objects

18UML - Patterns 18

Creational Patterns

Abstract Factory - provides an interface for creating families

19UML - Patterns 19

Structural PatternsAdapter - converts the interface of a class into another interface that clients

expect. It lest classes work together that could not otherwise because of incompatible interfaces

Bridge - decouples an abstraction from its implementation so that the two can vary independently

Composite - compose objects into tree structures to represent part-whole hierarchies. It lets clients treat individual objects and compositions of objects uniformly

Decorator - allows additional responsibilities to be attached to an object dynamically. It provides a flexible alternative to subclassing for extending functionality

Facade - provides a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use

Flyweight - uses a sharing scheme to support large numbers of fine grained objects efficiently

Proxy - controls access to an object by providing a surrogate or placeholder

20UML - Patterns 20

Behavioral PatternsChain of Responsibility - avoids coupling the sender of a request to its

receiver by giving more than one object a chain to handle the request. The receiving objects are chained, and the request passed along the chain until it is handled

Command - encapsulates a request as an object, thus allowing clients to be parameterized by different requests, to dequeue or log requests and to support undoable operations

Interpreter - defines a representation for a language's grammar and an interpreter that uses the representation to interpret sentences in the language

Iterator - provides a way to access the elements of an aggregate object sequentially, without exposing its underlying implementation

Mediator - defines an object that encapsulates how a set of objects interact. It promotes loose coupling by keeping objects from referring to each other explicitly, and allowing their interactions to be varied independently

Memento - captures and externalizes an object’s internals, without violating encapsulation, so that the object can be resorted to this state later

21UML - Patterns 21

Behavioral Patterns (Continued)

Observer- defines a one-to-many dependency between objects so that when one object changes its state, all its dependents are notified and updated automatically

State - Allows an object to alter its behavior when its internal state changes. The object appears to change its class

Strategy - defines a family of algorithms, encapsulates each one, and makes them interchangeable. It lets the algorithm vary independently from clients that use it

Template Method - defines the skeleton of an algorithm in an operation, deferring some steps to subclasses. It lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure

Visitor - represents an operation to be performed on the elements of an object structure. It lets you define a new operation without changing the classes of the elements on which it operates

22UML - Patterns 22

Selecting a Design Pattern

consider how design patterns solve design problems

scan the “intent” sections

study how patterns interrelate

study patterns of like purpose

examine a cause of redesign

consider what should be variable in the design

23UML - Patterns 23

Using a Design Pattern

•1. read pattern description for an overview

•2. study Structure, Participants and Collaborations sections

•3. look at the Sample Code section

•4. choose participant names for application context

•5. define the classes

•6. define application-specific names for operations

•7. implement operation to carry out responsibilities

24UML - Patterns 24

Abstract Factory Pattern

INTENT - provides an interface for creating families of related or dependent objects without specifying their concrete classes

AKA - Kit

USE WHEN - a system should be independent of how its products are created, composed and represented

- a system should be configured with one of multiple families of products

- a family of related products is designed to be used together, and you need to enforce this constraint

- you want to provide a class library of products, and you want to reveal just their interface, not their implementations

RELATED - concrete factories are often singletons- can be implemented by Factory Method or Prototype

25UML - Patterns 25

Abstract Factory Pattern Continued

PARTICIPANTS - AbstractFactory- ConcreteFactory- AbstractProduct- ConcretePoduct- Client

COLLABORATIONS

CONSEQUENCES

- normally a single instance of ConcreteFactory is created at runtime. This concrete factory creates product objects having a particular implementation. To create different product objects, clients should use a different concrete factory

- AbstractFactory defers creation of product objects to its ConcreteFactory- concrete classes are isolated

- exchanging product families is easyKNOWN USES - Interviews (Kit suffix denotes abstract factories)

- ET++

26UML - Patterns 26

Abstract Factory Structure

ConcreteFactory1

CreateProductA()CreateProductB()

AbstractFactory

CreateProductA()CreateProductB()

ProductB2

ConcreteFactory2

CreateProductA()CreateProductB() ProductB1

AbstractProductB

ProductA2 ProductA1

AbstractProductAClient

27UML - Patterns 27

Abstract Factory Example

MotifWidgetFactory

WidgetFactory

CreateScrollBar()CreateWindow() PMScrollBar

PMWidgetFactory

MotifScrollBar

ScrollBar

PMWindow MotifWindow

WindowClient

CreateScrollBar()CreateWindow()

CreateScrollBar()CreateWindow()

28UML - Patterns 28

Strategy Pattern

INTENT - defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use itAKA - Policy

USE WHEN - many related classes differ only in their behavior. Strategies provide a way to configure a class with one of many behaviors

- different variants of an algorithm are required- an algorithm uses data that clients should not

know about. The strategy pattern can be used to avoid exposing complex, algorithm-specific data structures

- a class defines many behaviors, and these appear as multiple conditional statements in its operations. The related conditional branches can be moved into their own strategy class- strategy objects often make good flyweightsRELATED

29UML - Patterns 29

Strategy Pattern Continued

PARTICIPANTS - Strategy- ConcreteStrategy- Context

COLLABORATIONS

CONSEQUENCES

- Strategy and Context interact to implement the chosen algorithm

- a context forwards requests from its clients to its strategy

- families of related algorithms are available- provide an alternative to subclassing- no conditional statements for selecting behavior- provide different implementations- clients must be aware of different strategies- communication overheads - Increased number of objects

- Interviews ET++ for line breaking algorithmsKNOWN USES

30UML - Patterns 30

Strategy Structure

ConcreteStrategyC

AlgorithmInterface()

ConcreteStrategyB

AlgorithmInterface()

ConcreteStrategyA

AlgorithmInterface()

Strategy

AlgorithmInterface()

Context

ContextInterface()

strategy

31UML - Patterns 31

Composite Structure

Composite

Operation()Add(component)Remove(Component)GetChild(int)

forall g in children g.Operation

Component

Operation()Add(component)Remove(Component)GetChild(int)

Leaf

Operation()

Client

children

32UML - Patterns 32

Typical Composite Object Structure

aComposite

aLeaf aLeaf aLeafaComposite

aLeaf aLeaf aLeaf

33UML - Patterns 33

Typical Example of Composite

Picture

Draw()Add(Graphic g)Remove(Graphic)GetChild(int)

forall g in graphics g.Operation

Graphic

Draw()Add(Graphic)Remove(Graphic)GetChild(int)

Text

Draw()

graphics

Line

Draw()

Rectangle

Draw()

add g to list of graphics

34UML - Patterns 34

Recursively Composed Graphics Objects

aPicture

aRectangleaPicture

aLine aText aRectangle

aLine

UML - Patterns 35

Frameworks

• Integrated set of components that collaborate to provide a reusable architecture for a family of related applications

• Ex: Microsoft Foundation Classes, ACE• Enable direct reuse of code• Facilitate large scale reuse• High inital learning curve