Software design: Lecture 40 - Sheraz Pervaiz

Software design - Lecture 40. The main topics covered in this chapter include: observer design pattern or publish and subscribe; motivation for observer design pattern; one data multiple representations; newspaper subscription example; case for observer design pattern;...

Lecture : 40

OR

Publish and Subscribe

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

One Data multiple Representations

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

•  

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 

 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

Newspaper Subscription Example

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

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

“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”

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

Class Diagram

Sequence Diagram

 Support for event broadcasting

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

 Liabilities:

 Possible cascading of notifications

    Observers are not necessarily aware of each other and must be careful about triggering updates

 Java provides the Observable/Observer classes as  built­in support for the Observer pattern.

 The java.util.Observer interface is the Observer 

interface. 

 It must be implemented by any observer class.

Sample Code

public PriceObserver() {

price = 0;

System.out.println("PriceObserver created: Price is " + price);}

public void update(Observable obj, Object arg) {

if (arg instanceof Float) {

price = ((Float)arg).floatValue();

System.out.println("PriceObserver: Price changed to " + price);} else {

System.out.println(”PriceObserver: Some other change to 

subject!"); }

}