Software design: Lecture 40 - Sheraz Pervaiz

1

Software Design
Lecture : 40


2

Observer Design Pattern 
OR

Publish and Subscribe


3

Motivation for Observer Design 
Pattern
 When  we  partition  a  system  into  a  collection  of 
cooperation  classes,  it  is  desired  that  consistent  state 
between participating objects is to be maintained.

 This should be not achieved via tight coupling as against 
our basis design principle because for obvious reason this 
will reduce reusability


4

One Data multiple Representations

5

Myth about the Diagram
 Bar Graph and Pie Chart don’t know about each other  so 
that  any  one  can  be  reused  independent  of  each  other, 
but  the  interesting thing is that it seems that they know 
each other. How???

 When  the  data  in  the  spreadsheet  is  changed  it  is 
reflected in pie chart and bar graph also immediately

• 


6

Myth about the diagram
 This behavior implies that they are dependent on data of 
the  spreadsheet  and  when  ever  there  is  a  change  in 
spreadsheet pie chart and bar graph is notified to update 
the change.

 There seems to be no reason to believe that the number 
of objects representing the data is to be limited may be i­
e  may  be  line  graph  is  to  be  used  in  future  to  represent 
data 


7

Observations
 There exists a consistent communication model between 
a  set  of  dependent  objects  and  an  object  that  they  are 
dependent on.

 This  allows  the  dependent  objects  to  have  their  state 
synchronized with the object that they are dependent on.


8

Observers and Subjects (Observable)
The set of dependent objects are referred to as
    Observers i­e Graphs in our example

The  object  on  which  Observer    dependent  is 
referred  to  as  the  subject.  i­e  Spreadsheet  in  our 
example


9

Newspaper Subscription Example


10

Case for Observer Design Pattern
 Observer  pattern  suggests  a  publisher­subscriber  model 

leading to a clear boundary between the set of Observer 
objects and the Subject object.

 A  typical  observer  is  an  object  with  interest  or 
dependency in the state of the subject.


11

Case for Observer Design Pattern
 The subject cannot maintain a static list of such observers 
as  the  list  of  observers  for  a  given  subject  could  change 
dynamically.  Hence  any  object  with  interest  in  the  state 
of  the  subject  needs  to  explicitly  register  itself  as  an 
observer with the subject
 Whenever  the  subject undergoes a change in its state, it 
notifies  all  of  its  registered  observers.  Upon  receiving 
notification  from  the  subject,  each  of  the  observers 
queries  the  subject  to  synchronize  its  state  with  that  of 


12

One – to Many Relationship
 In  other  words,  the  scenario  contains  a  one­to­many 
relationship  between  a  subject  and  the  set  of  its 
observers.

 Each of the observer objects has to register itself with the 
subject  to  get  notified  when  there  is  a  change  in  the 

subject’s state


13


14

Observer Pattern Defined
“This 

pattern 

defines 

a 

one­to­many 

relationship  between  objects  so  that  when 
there is change in the state of the one object it 
should be notified and automatically updated 
to all of it’s dependent”


15

Communication Mechanism
 The  subject  should  provide  an  interface  for  registering 
and unregistering for change notifications.

In  the  pull  model  —  The  subject  should  provide  an 
interface  that  enables  observers  to  query  the  subject  for 
the required state information to update their state.

In  the  push  model  —  The  subject  should  send  the 
state information that the observers may be interested in.


16

Class Diagram


17


18

Sequence Diagram


19


20

Consequences
Support for event broadcasting

Minimal  coupling  between  the  Subject  and  the 
Observer  .  Reuse  obervers  without  using  subject 
and vice verca


21

Consequences
Liabilities:
 Possible cascading of notifications
        Observers  are  not  necessarily  aware  of  each  other  and 
must be careful about triggering updates


22

Observer Pattern in Java
Java provides the Observable/Observer classes as 
built­in support for the Observer pattern.
The java.util.Observable class is the base Subject class. 
i. Any class that wants to be observed extends this class.
ii. Provides methods to add/delete observers
iii. Provides methods to notify all observers
iv.  A  subclass  only  needs  to  ensure  that  its  observers  are 
notified in the appropriately
v. Uses a Vector for storing the observer references


23

Observer Interface
The java.util.Observer interface is the Observer 
interface. 

It must be implemented by any observer class.


24

Sample Code


25

public class ConcreteSubject extends Observable {
private String name; // To be observed
private float price;
public ConcreteSubject(String name, float price) {
this.name = name;
this.price = price;
System.out.println("ConcreteSubject created: " + name + " 
at “ + price);
}