7/31/2019 Daily Patterns #14

1/3

observer designpattern...

Intent

Define a one-to-many dependency between objectsso that when one object changes state, all its

dependents are notified and updated automatically.

Encapsulate the core (or common or engine)components in a Subject abstraction, and the

variable (or optional or user interface) componentsin an Observer hierarchy.

The View part of Model-View-Controller.

PROBLEM

A large monolithic design does not scale well asnew graphing or monitoring requirements are levied.

Define an object that is the keeperof the data model and/or businesslogic (the Subject). Delegate all

view functionality to decoupled anddistinct Observer objects. Observersregister themselves with the Subject

as they are created. Whenever theSubject changes, it broadcasts to all

registered Observers that it haschanged, and each Observer queriesthe Subject for that subset of the

Subjects state that it is responsiblefor monitoring.

This allows the number and type ofview objects to be configureddynamically, instead of being

statically specified at compile-time.

The protocol described abovespecifies a pull interaction model.

Instead of the Subject pushing whathas changed to all Observers, each

Observer is responsible for pullingits particular window of interestfrom the Subject. The push model

compromises reuse, while the pullmodel is less efficient.

Issues that are discussed, but left tothe discretion of the designer, include:implementing event compression (only

sending a single change broadcastafter a series of consecutive changes

has occurred), having a single Observermonitoring multiple Subjects, andensuring that a Subject notify its

Observers when it is about to go away.

The Observer pattern captures the

lions share of the Model-View-Controller architecture that has beena part of the Smalltalk community for

years.

htt

p:/

/

www

.youtube

.com/

wat

ch?

v=

rWvXJ

o3OAzs

http://www.youtube.com/watch?v=rWvXJo3OAzshttp://www.youtube.com/watch?v=rWvXJo3OAzshttp://www.youtube.com/watch?v=rWvXJo3OAzshttp://www.youtube.com/watch?v=rWvXJo3OAzs

7/31/2019 Daily Patterns #14

2/3

Structure

Subject represents thecore (or independent or

common or engine)abstraction. Observer

represents the variable(or dependent or

optional or userinterface) abstraction.

The Subject prompts theObserver objects to do

their thing.

Each Observer can callback to the Subject as

needed.

The Observer defines a one-to-manyrelationship so that when one objectchanges state, the others are notified

and updated automatically. Some auctionsdemonstrate this pattern. Each bidderpossesses a numbered paddle that isused to indicate a bid. The auctioneer

starts the bidding, and observes when apaddle is raised to accept the bid. Theacceptance of the bid changes the bid

price which is broadcast to all of thebidders in the form of a new bid.

Differentiate between the corefunctionality and the optional

functionality.

Model the independent functionalitywith a subject abstraction.

Model the dependent functionality withan observer hierarchy.

The Subject is coupled only to theObserver base class.

The client configures the number andtype of Observers.

Observers register themselves withthe Subject.

The Subject broadcasts events to allregistered Observers.

The Subject may push information atthe Observers, or, the Observers maypull the information they need from

the Subject.

7/31/2019 Daily Patterns #14

3/3

Chain of Responsibility, Command, Mediator, and Observer, address how you candecouple senders and receivers, but with different trade-offs. Chain of

Responsibility passes a sender request along a chain of potential receivers.Command normally specifies a sender-receiver connection with a subclass.

Mediator has senders and receivers reference each other indirectly. Observerdefines a very decoupled interface that allows for multiple receivers to be

configured at run-time.

Mediator and Observer are competing patterns. The difference between them isthat Observer distributes communication by introducing observer and

subject objects, whereas a Mediator object encapsulates the communicationbetween other objects. Weve found it easier to make reusable Observers and

Subjects than to make reusable Mediators.

On the other hand, Mediator can leverage Observer for dynamically registeringcolleagues and communicating with them.

The Observer patternis criticized for

being too verbose,introducing too many

bugs and violatingsoftware

engineeringprinciples, such as

not promoting side-

effects,encapsulation,composability,separation ofconcepts,scalability,uniformity,

abstraction,resource

management,semantic distance.The recommended

approach is togradually deprecateobservers in favor

of reactiveprogrammingabstractions.

The class java.util.Observer provides a simpleobserver implementation.

Events are typically implemented in Java through thecallback pattern: one piece of code provides a common

interface with as many methods as many events arerequired, another piece of code provides an

implementation of that interface, and another onereceives that implementation, and raises events as

necessary.