Technieken van de Software Architectuur, VUB ‘98-’99, Part 41 Part 4: Design Patterns.

Technieken van de Software Architectuur, VUB ‘98-’99, Part 4 1

Part 4: Design Patterns


Background

Designing reusable software is difficult» Finding good objects and abstractions» Flexibility, Modularity, Elegance» Takes time to emerge, trial and error

Successful designs exist How to describe recurring structures

» Deja-Vu feeling, don’t reinvent the wheel, don’t reinvent the flat tire.

Design Patterns: Elements of Reusable Object Oriented Software

» E. Gamma R. Helm R. Johnson J. Vlissides


Design Patterns

Design patterns capture successful solutions to recurring problems that arise during software construction

Design patterns help to improve key software quality factors

Design patterns support reuse of software architectures


A Design Pattern

Describes a recurring design structure» Used twice rule» Names, abstracts from concrete designs» Identifies classes, collaborations,

responsibilities» Applicability, trade-offs, consequences,

language issues

Is discovered, not invented


Practical Experience

Design Patterns are based on practical solutions found in main-stream applications implemented in Smalltalk and C++» Windowing Systems» CAD» Banking» Persistent Objects» Distributed Systems» ...


Describing Design Patterns

Pattern name and classification

Intent Also Known As Motivation Applicability Structure

Participants Collaborations Consequences Implementation Sample Code Known Uses Related Patterns


Catalogue of Design Patterns

Purpose» Creational» Structural» Behavioural

Scope» Class» Object


Structural Patterns

Adaptor Bridge Composite Decorator Facade Flyweight Proxy


Behavioural Patterns

Chain of Responsibility

Command Interpreter Iterator Mediator Memento

Observer State Strategy Template Method Visitor


Design Coverage

Large Portion of design covered by patterns» Most classes play role in some patterns» Improved understanding

Seductively simple to implement patterns You still have to write functionality

» Common mistake is to think design patterns solve your problems


Abstract Factory


Abstract Factory

Object Creational Intent: Provide an interface for creating

families of objects without specifying the concrete classes

Motivation: Creation of line segments, points, ... in a drawing framework


Abstract Factory: Motivation

ComponentFactory

newLine() {abstract}newPoint() {abstract}

GrayComponentFactory

newLine()newPoint()

ColorComponentFactory

newLine()newPoint()

Client

Line

ColorLine GrayLine

Point

ColorPoint GrayPoint


Abstract Factory: Applicability

Use the Abstract Factory Pattern when:» A system has to be independent of how its

objects are created, composed and represented

» Configuration with families of products is necessary

» A family of products is designed to work together


Abstract Factory: Participants

AbstractFactory (e.g. ComponentFactory)

ConcreteFactory (e.g. ColorComponentFactory)

AbstractProduct (e.g. Point) ConcreteProduct (e.g. ColorPoint) Client


Abstract Factory: Consequences

It isolates clients from concrete classes Makes exchanging of product families

easier It promotes consistency amongst

products Supporting new kinds of products is

difficult


Abstract Factory: Implementation

Factories are best implemented as Singletons

Creating the products» (1) Use a Factory Method for each product» (2) Initialize the concrete factory with a

prototypical instance that can be copied

Defining extensible factories» In AbstractFactory provide a parameter to

identify the product to be created


Bridge


Example: Variations in storage

InformixProgram

... findPrograms ...

Program

duration()productCode()broadcastitle (title: Title)static findPrograms (s:searchObject) : ProgramList...

IngresProgram

... findPrograms

OracleProgram

... findPrograms


The Original Persistency Layer

Allow non DB experts to work on the application Migration to other DB's Be ready for OO databases

Domain Model

Persistency Layer

Store

Retrieve

HematomasHematomas


bcPIDProgramID contractPID

Example

Program

contractPeriodbroadcastPeriod

Period

from: 01/01/96, 00h00 to: 01/02/96, 00h00

from: 07/01/96, 20h00 to: 07/01/96, 22h00

Period

ProgramTable:

PeriodTable: PeriodID fromDate fromHour toDate toHour

foreign key


Solution: Bridge Pattern

Intent: Decouple an abstraction from its implementation so that the two can vary independently

Motivation: Window Implementations


Bridge: Motivation

Window

DrawText()DrawRect

WindowImp

DrawText()DrawRect

TransientWindow

DrawCloseBox

IconWindow

DrawBorder()

Window95Imp

DrawText()DrawRect

XWindowImp

DrawText()DrawRect

Imp


Bridge: Applicability

Use the Bridge Pattern to» Avoid a permanent binding between an

abstraction and its implementation» Both the abstractions and their implementations

should be extensible by subclassing» To avoid proliferation of classes

Separation of Concerns


Bridge: Structure

Abstraction

Operation()

Implementor

OperationImp()imp

RefinedAbstraction

ConcreteImpB

OperationImp()

ConcreteImpA

OperationImp()

Client

Bridge Participants


Bridge: Consequences

Decoupling interface and implementation Improved extensibility Hiding implementation details from clients


Implementation ObjectKnows how to map itself to a relational database

Implementation ObjectKnows how to map itself to a relational database

The Bridge Architecture

A

B

C+D

Conceptual ObjectContains business rules


DomainObjectstore()initialize()storage ()

The Bridge Architecture

StorageObject

...Programtitle(t:Title)

BasicStorage AdaptorStorage

FlattenedStorage

HierarchyStorage

Mapping Strategies

storagedomain


Bridge: Basic Mappings

DomainObjectstore()initialize()...

StorageObject

Firmname(s:String)...

BasicStorage

FirmStoragename:Stringname (s:String)...

name [name]

nameaddr...

PSIFirmTable


Bridge: Basic Mappings

A commercially available framework is used for the basic mappings (Object Lens)

The abstract classes contain behavior for querying, retrieval, etc. of data

The basic mappings are database independent


Bridge: Mappings of Classes

A

B

C C

B

A+B+C

A

FlattenedStorage

HierarchyStorage


FlattenedStorage

Bridge: FlattenedStorage

DomainObject

Contract

SalesContract PurchaseContract

StorageObject

BasicStorage

ContractStorage

date:Stringdate (s:String)

...

nameaddrclassID


BProgramStorage

Bridge: HierarchyStorage

DomainObject

Program

Episode

StorageObject

BasicStorage

BEpisodeStorage

HierarchyStorage

ProgramStorage

EpisodeStorage

programPart

episodePart


Bridge: Adaptor Mapping

Program

broadcastPeriodcontractPeriod

Period

from: 01/01/96, 00h00 to: 01/02/96, 00h00

from: 07/01/96, 20h00 to: 07/01/96, 22h00

Period

ProgramTable

bcFromDatebcFromTimebcToDatebcToTimecntrFromDatecntrFromTime...

bcFromDatebcFromTimebcToDatebcToTimecntrFromDatecntrFromTimecntrToDatecntrToTime

ProgramStorage

Conceptual Objects Implementation Objects

BCPeriodStorage

Database

toDate[toDate]

toDate[bcToDate]


Bridge: Adaptor Mapping

DomainObjectstore()initialize()...

StorageObject

Periodfrom():Timeto(): Time

BasicStorage

ProgramStoragebcFrom:DatebcTo:Date

AdaptorStorage

BCPeriodStoragefrom():Timeto():Time

Adaptor design pattern

to [bcTo]

adaptee


Adaptors

Period

to():Timefrom(): TimeincludesTime(t:Time):Booleanmerge(p:Period):Period

PeriodAdaptor

PeriodImpl

to:Timefrom: Timeto():Timefrom(): Time

Period

to():Timefrom(): TimeincludesTime(t:Time):Booleanmerge(p:Period):Period


Observer


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.

15,20,40

Motivation: Maintain consistency between objects without a tight coupling that reduces reusability.


Observer : Applicability

Use Observer when» an abstraction has two aspects, one dependent on the

other. Encapsulating these aspects in separate objects lets you vary and reuse them independently.

» a change to one object requires changing others, and you don’t know how many objects need to be changed

» an object should be able to notify other objects without making assumptions about who these objects are.



Observer : Structure

Subject

attach(Observer)dettach(Observer)Notify()

Observer

update()

ConcreteObserverobserverState

update()

state

ConcreteSubjectsubjectState

getState()setState()

forall o in observers o update

return subjectStateobserverState= subject subjectState

Observer Participants


Observer : Consequences

abstract coupling between subject and observer

support for broadcast communication unexpected updates


State


State

Object Behavioral Intent: Allow an object to alter its

behavior when its internal state changes. The object will appear to change its class

Motivation: Network connection


State: Motivation

TCPConnection

open ()close()

TCPState

clone()

TCPListen

open()close()

TCPClosed

open()close()

state

TCPEstablished

open()close()state close()


State : Applicability

Use State» when an object’s behavior depends on its

state and it must chaneg its behavior at runtime

» when operations have large conditional statements that depend on the state of the objects


State : Participants

Context (e.g. TCPConnection) State (e.g. TCPState) ConcreteState (subclasses of State)


State : Structure

Context

request()

State

handle()

TCPListen

handle()

TCPClosed

handle()

state

TCPEstablished

handle()state handle()


State : Consequences

separates state-specific behavior from general behavior

Makes state-transitions explicit State objects can be shared


Composite


BUT?

How to combine ?- multiple inheritance- mixin classes

+

Node

LoggingNode WorkstationPrintserver

Node

Separate discussion(design patterns)


...

...

Program

duration()productCode()broadcastitle (title: Title)static findPrograms (s:searchObject) : ProgramList...

Example: Variations in the domain

Series

...

Episode

...

... ...


Example: Variations in the domain

ComposedProgram

duration ()

Program

duration()broadcastitle (title: Title)static findPrograms (s:searchObject) : ProgramList...

ProgramSlice

duration ()


Combining variations

Duplication of behavior » Not a satisfying solution» Proliferation of versions

Concentrate behaviour» Not a satisfying solution» Overfeaturing

ProgramSlice

Program

Episode

EpisodeSlice

Program

isSlice...


Composite Programs

ComposedProgram

duration ()

Program

duration()...

SeriesEpisode

duration [duration]


A Solution

Program

duration()...

SeriesEpisode

Structure

duration()...

Composedduration()

Atomicduration()

Slicedduration()

concretisationparts

duration [duration]


State design pattern

Composite design pattern

structure


Decorator


Decorator: Participants

Component (e.g. VisualComponent) ConcreteComponent (e.g. TextView) Decorator (e.g. Decorator) ConcreteDecorator (e.g.

BorderDecorator)


Decorator: Structure

Component

Operation()

ConcreteComponent

Operation()

Decorator

Operation()

component

ConcreteDecoratorAadded stateOperation()added behaviour

ConcreteDecoratorBadded stateOperation()added behaviour

component operation

super operationadded behaviour


Decorator: Consequences

More flexible than static inheritance. Avoids classes with a lot of features

» Refactoring method !» Lots of little objects» Avoids duplication of features

Object identity can be a problem


Decorator: Participants

Component (e.g. VisualComponent) ConcreteComponent (e.g. TextView) Decorator (e.g. Decorator) ConcreteDecorator (e.g.

BorderDecorator)


Decorator: Structure

Component

Operation()

ConcreteComponent

Operation()

Decorator

Operation()

component

ConcreteDecoratorAadded stateOperation()added behaviour

ConcreteDecoratorBadded stateOperation()added behaviour

component operation

super operationadded behaviour


Decorator: Consequences

More flexible than static inheritance. Avoids classes with a lot of features

» Refactoring method !» Lots of little objects» Avoids duplication of features

Object identity can be a problem


Design Patterns in Practice

Architectural Layers

Integration

Redundancy

Data Warehousing


Firstname

Lastname

Age

Person Editor

Person

Person

Reusable Objects/Components


Firstname

Lastname

Age

Person Editor

Person

Person

Application Layer

Application Layer

Domain Layer

Domain Layer

Persistency Layer

Persistency Layer



Application LayerApplication Layer

Domain LayerDomain Layer

Persistency LayerPersistency Layer

Drawing Editor Firstname

Lastname

Age

Person Editor

License

Brand

Age

Car Editor

Person

CarDrawing

Layered Architecture


Bridge: Integration

PSI

PSI DB

OtherApplication

External DB

Bridge


Controlling Redundancy

FirmID

Firm Name

Title

Program Editor StorageObject

BasicStorage

FirmStoragename:Stringname (s:String)id: Sringid (s:String)

ProgramStoragefirmName:StringfirmName (s:String)firmId: SringfirmId (s:String)...

Updates programStorage if name or

id changes


Data Warehousing: CASE

NumberAmount

Owner

Account Editor

Application

RDBMSMainframe

Application for account managementCICS Transactions Mirrored DB...


AccountStorage

amount(): Integerowner(): Owner...


Account


storage

Brid

ge

NumberAmount

Owner

Account Editor


AccountStorage



Account


storage

Brid

ge

NumberAmount

Owner

Account Editor

Transaction

CICS

CICS1234

CICS1235

Adaptor


AccountStorage



Account


storage

Brid

ge

NumberAmount

Owner

Account Editor

Transaction

CICS

CICS1234

CICS1235

Adaptor

CICSAccountAmount

set(amount: Integer)get(): Integer

Facade


Data Warehousing

Account


storageAccountStorage


Transaction

CICS

CICS1234

CICS1235

CICSAccountAmount

set(amount: Integer)get(): Integer

Facade

Adaptor

AccountBasicStorage

Brid

ge

NumberAmount

Owner

Account Editor


Bridge: Summary

Provides a clean separation between domain and storage

Allows easy integration with other systems

Various mappings had to be included» NOT part of the Bridge Design Pattern

Technieken van de Software Architectuur, VUB ‘98-’99, Part 41 Part 4: Design Patterns.

Documents

Transcript of Technieken van de Software Architectuur, VUB ‘98-’99, Part 41 Part 4: Design Patterns.