Design Patterns

Source: “Design Patterns”, Erich Gamma, Richard Helm, Ralph Johnson,

John Vlissides

And http://java.sun.com/blueprints/patterns

Created By Eshcar Hilel

Design Patterns 2

Agenda

• Design Patterns - Why?• Model-View-Controller Pattern

– What Is the Problem?– Solution, Structure, Responsibilities– Class Diagram

• Observer Pattern• (Composite Pattern)• Strategy Pattern• MVC variants examples

Design Patterns 3

Design Patterns - Why?

• Designing OO software is hard• Designing reusable OO software – harder• Experienced OO designers make good

design• New designers tend to fall back on non-OO

techniques used before• Experienced designers know something –

what is it?

Design Patterns 4

Design Patterns - Why?

• Expert designers know not to solve every problem from first principles

• They reuse solutions

• These patterns make OO designs more flexible, elegant, and ultimately reusable

Analogy I - Novelists and playwrights:“Tragically Flawed Hero” (Macbeth,

Hamlet...)

“The Romantic Novel”

Analogy II – Telenovela!!

Design Patterns 5

Two Major Principles of Object-Oriented Design:

• Program to an interface, not an implementation.

• Favor object compositions over class inheritance.

Dynamic binding,

polymorphism...

White-box reusevs.

Black-box reuseSee more of this in…

OOD

Design Patterns 6

Model-View-Controller Pattern

• MVC consists of three kinds of objects:– Model – the application object– View – UI (screen presentation)– Controller – defines the way the UI reacts to

user inputs

Design Patterns 7

MVC – What Is the Problem?

• The same enterprise data needs to be accessed when presented in different views: e.g. HTML, JFC/swing, XML

• The same enterprise data needs to be updated through different interactions

• Supporting multiple types of views and interactions should not impact the components that provide the core functionality of the enterprise application

Design Patterns 8

MVC – Solution

• Separate core business model functionality from the presentation and control logic that uses this functionality

• Allows multiple views to share the same enterprise data model

• Makes supporting multiple clients easier to implement, test, and maintain

Design Patterns 9

MVC Structure

Design Patterns 10

MVC – Responsibilities

• Model - the model represents enterprise data and the business rules that govern access to and updates of this data

• View -the view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented

• Controller - the controller translates interactions with the view into actions to be performed by the model

Design Patterns 11

IObserver

update()

(from view)

<<Interface>>BasicSubject

notify()

(from model)

0..n0..n

-observers

IControllerStrategy(from controller)

<<Interface>>

StateObserver(from view)

11

-strategy

StorageSubject(from model)

11

-subject

ControllerStrategy(from controller)

11

-viewObject

11

-modelObject

MVC – Class Diagram

Design Patterns 12

MVC – Class Diagram

Observer Pattern

Strategy Pattern

IObserver

update()

(from view)

<<Interface>>BasicSubject

notify()

(from model)

0..n0..n

-observers

IControllerStrategy(from controller)

<<Interface>>

StateObserver(from view)

11

-strategy

StorageSubject(from model)

11

-subject

ControllerStrategy(from controller)

11

-viewObject

11

-modelObject

Design Patterns 13

ISubjectManager(from model)

<<Interface>>

StorageSubject(from model)

IObserver

update()

(from view)

<<Interface>>BasicSubject

notify()

(from model)

0..n0..n

-observers

IControllerStrategy(from controller)

<<Interface>>

ISubjectState(from model)

<<Interface>>StateObserver

(from view)

11

-strategy0..10..1

-subject

ControllerStrategy(from controller)

11

-viewObject

11

-modelObject

MVC – Class Diagram (including interfaces)

Design Patterns 14

ISubjectManager(from model)

<<Interface>>

StorageSubject(from model)

IObserver

update()

(from view)

<<Interface>>BasicSubject

notify()

(from model)

0..n0..n

-observers

IControllerStrategy(from controller)

<<Interface>>

ISubjectState(from model)

<<Interface>>StateObserver

(from view)

11

-strategy0..10..1

-subject

ControllerStrategy(from controller)

11

-viewObject

11

-modelObject

MVC – Class Diagram (including interfaces)

controller

view

model

Design Patterns 15

Observer PatternClass Diagram

Subject

attach(ob : Observer)detach(ob : Observer)notify()

Observer

update()

<<Interface>>

0..n0..n

ConcreterObserverConcreteSubject

getState()setState()

-subject

-observers

Design Patterns 16

Observer Pattern

• Define a one-to-many dependency, all the dependents are notified and updated automatically

• The interaction is known as publish-subscribe or subscribe-notify

• Avoiding observer-specific update protocol: pull model vs. push model

• Other consequences and open issues

Design Patterns 17

Observer Pattern Sequence Diagram??? : ConcreteSubject ob1 :

ConcreterObserverob2 :

ConcreterObserver

notify( )

update( )

getState( )

update( )

getState( )

for each observer

Design Patterns 18

Composite Pattern

• View can be nested

• Described by the Composite design pattern seen in the lecture

Design Patterns 19

Strategy Pattern – Class Diagram

Context Strategy

algorithmInterface()

<<Interface>>-strategy

ConcreteStrategyA ConcreteStrategyB

Design Patterns 20

Strategy Pattern

• Define family of algorithms, encapsulates them and make them interchangeable

• Eliminate conditional statements

• Cons: communication overhead, increase number of objects

MVC Variants

Design Patterns 22

Three Tier Model

Design Patterns 23

MVC in Eliza

ElizaUI<<ElizaModelInterface>>

ElizaModel

implem

ents

The End