lecture 8: implementing observer pattern

LECTURE 8:IMPLEMENTING OBSERVER PATTERN

CSC 313 – Advanced Programming Topics

Today’s Goal

Review design patterns (tools) purpose What is needed so that a tool becomes

useful? Why can tools suck and how do we avoid

this? What does this mean for design

patterns? Observer pattern implementation

discussed How do we handle Observer addition &

removal? What do update methods need to be

useful? Why do we have to talk about pushing &

pulling? Coding “gotchas” discussed &

diagnosed

Design Pattern Intent

Design patterns are tools Like all tools, have reason for being

Design Pattern Intent

Design patterns are tools Like all tools, have reason for being

Design patterns are tools Like all most tools, have reason for being

Design Pattern Intent

Design patterns are tools Like all most tools, have reason for being Explains when & where to use pattern

When used improperly, tool is sad Bieber always depressed; Seacrest not

much better To be useful, need & pattern MUST

match Coding is simple when used properly More importantly, life just sucks when you

don’t

Design Pattern Intent

Strategy Pattern Intent

Strategy Pattern Details

Make family of algorithms interchangable Avoid duplicating code across classes &

projects Allows to change algorithm dynamically

Implementation easy when used correctly Everything relies on interface defining

behaviors Each strategy defines method to perform

some action Write into the context class has field of

interface type Call field’s method (delegate) to perform

action

Observer Pattern Intent

Observer Pattern Intent

Efficiently perform 1-to-many communication Easy to respond dynamically when

event(s) occurs Can create many, many possible actions to

occur Update which actions used throughout

execution Can also use to break mutual

dependency UML class diagram cycles split and

managed Dirty & ugly hack that also is incredibly

useful

Observer Pattern Examples

Where have you seen Observer Pattern?

Registering an Observer

Subject adds & removes Observers as needed Adding is simple Events also simple, call Observers’ update

method Removing not so simple, but not very hard

either Requires some means of holding

Observers Array ArrayList or LinkedList HashMap

Registering an Observer

Subject adds & removes Observers as needed Adding is simple Events also simple, call Observers’ update

method Removing not so simple, but not very hard

either Requires some means of holding

Observers Array*

ArrayList or LinkedList HashMap

* Anyone who did not object to this, fails.

Getting the Word Out

Calling Observers’ update methods is simple But for call Observer needs associated

information Not always clear what is best way to share

this data Must understand strengths & weaknesses

of each

Observer’s Push Model

Easiest approach is pattern’s push model Subject pushes data onto Observers Parameters used in call provides all data

needed Writing & using is simple with this

model, but… Once this is defined, stuck with data to be

shared Adding data hard, since must rewrite all

Observers Removal easier, but users guessing why

param exists

Observer’s Pull Model

Another approach using pattern’s pull model Subject provides instance to Observers

in the call To get data, Observer calls instance’s

methods Extend instance’s interface to make more

available But Observers using original methods still

work Making instances simple part of this

process Will need to have family of algorithms Used interchangeably, but only 1 used at a

time

Observer’s Pull Model

Another approach using pattern’s pull model Subject provides instance to Observers

in the call To get data, Observer calls instance’s

methods Extend instance’s interface to make more

available But Observers using original methods still

work Making instances simple part of this

process Just need to use Strategy Pattern

Pull Model’s Pros and Cons Communicating using Strategy pattern

means:

Observers & Subject independent of each other Subject provides the strategy to Observer

Subject & strategy semi-independent of other Subject source of event that strategy

communicates

Observer needs strategy & must change together

Problems with Pull Model

Pull model also has its problems May need multiple calls to get all the

data Need to consider multi-threaded access

issues Interfere with other design patterns, also

possible At the same time, problems easier &

harder If not multi-threaded, that issue can be

ignored As we will see, method calls can cost

nothing Just be careful & be certain of your

decision

Other Observer Gotchas

Observer only needs some of the events Intent is to perform 1-to-many

communication Subject cannot filter events for each

Observer Better to create addition Observer to do

filtering Subject has multiple sets of events to

observe Could choose to rely on single Observer

interface Java AWT/Swing libraries use this approach

Multiple Observer interfaces each with 1 event Simpler, but less efficient if multiple events

wanted

For Next Lecture

Read pages 70 – 74 in book Is this part of Java; what does

Observable do? How would one use it? Was there anyone with IQ over 80 to

correct it?