DejaVU Online: OO

[2] DejaVU Online: Principles of Object-Oriented Software Development (©)

[2] - [up] [top] - [I] [II] [III] [IV] - [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] - [A] [R]

Abstract event systems

intro polymorphism idioms patterns events summary, Q/A, literature

To conclude this chapter about idioms and patterns, we will look at a somewhat more detailed example employing (user-defined) events to characterize and control the interaction between the objects. The example is taken from [Henderson93]. The abstract system, or repertoire of statements indicating the functionality of our application is depicted in slide as-system.

  th = new centigrade();
  th = new fahrenheit();
  th.set(f);
  f = th.get();

For thermometer th, th1; float f;

slide: Abstract system -- thermometers

First, we will define the functional behavior of the system (in this case a collection of thermometers that record and display temperature values, as characterized above). Then we will introduce the user interface classes, respectively to update the temperature value of a thermometer and to display its value. After that we define a concrete event class (derived from an abstract event class) for each of the possible kinds of interactions that may occur. Then, after installing the actual objects comprising the system, we will define the dependencies between (actual) events, so that we can guarantee that interactions with the user will not result in an inconsistent state.

Functional behavior

A thermometer must provide the means to store a temperature value and allow for the changing and retrieving of this value. The temperature values are assumed to be stored in degrees Kelvin.

  class thermometer {    thermometer  


  
  protected thermometer( float v ) {  temp = v; }
  
  public void set(float v) { temp = v; }
  public float get() { return temp; }
  
  protected float temp;
  };

slide: The thermometer class

Since only derived classes can use the protected constructor, no direct instances of thermometer exist, so the class is abstract. We will distinguish between two kinds of thermometers, measuring temperatures respectively in centigrade and fahrenheit.

  class centigrade extends thermometer {    centigrade  


  
  public centigrade() {  super(0);  }
  public void set(float v) { temp = v + 273; }
  public float get() { return temp - 273; }
  };

slide: The centigrade class

The class centigrade redefines the methods get and set according to the measurement in centigrade, and in a similar way we may define the class fahrenheit.

  class fahrenheit extends thermometer {    fahrenheit  


  
  public fahrenheit() { super(0); }
  public void set(float v) { temp = (v - 32) * 5/9 + 273; }
  public float get() { return temp * 9/5 + 32 - 273; }
  };

slide: The fahrenheit class

Both the thermometer realization classes take care of performing the conversions necessary to store and retrieve the absolute temperature value.

User interface

We will define two simple interface classes, of which we omit the implementation details. First, we define the interface of the displayer class, needed to put values to the screen.

  class displayer extends window {    displayer  


  
  public displayer() { ... }
  public void put(String s) { ... }
  public void put(float f) { ... }
  };

slide: The displayer class

And secondly, we define a prompter class, which defines (in an abstract way) how we may get a value from the user (or some other component of the system).

  class prompter extends window {    prompter  


  
  public prompter(String text) { ... }
  public float get() { ... }
  public String gets() { ... }
  };

slide: The prompter class

Together, the classes displayer and prompter define a rudimentary interface which is sufficient to take care of many of the interactions between the user and the system.

Events

To define the interactions with the user (and their possible consequences) we will employ events, that is instances of realizations of the abstract event class, defined below.

  abstract class event {    event  


  pubic void dependent(event e) { ... }
  pubic void process() { ... }
  public void operator(); // abstract method
  
  private event[] dep;
  };

slide: The event class

Since a simple event (for example, the modification of a value) may result in a series of events (needed to keep the system in a consistent state), an event object maintains a set of dependent events, which may be activated using the process method. Further, each class derived from event is assumed to define the application operator, that is the actual actions resulting from activating the event. The first realization of the abstract event class is the update event class, which corresponds to retrieving a new temperature value from the user.

  class update extends event {    update  


  
  public update(thermometer th, prompter p) {
  	_th =th;  _p = p; 
  	}
  void operator()() {
  	_th.set( _p.get() );
  	process();
  	}
  
  thermometer _th;
  prompter _p;
  };

slide: The update class

An update involves a thermometer and a prompter, which are stored when creating the update event object. Activating an update event instance results in retrieving a value from the prompter, setting the thermometer to this value and activating the dependent events. In a similar way, we define the second realization of the abstract event class, the show event class, which corresponds to displaying the value of a thermometer.

  class show extends event {    show  


  
  public show(thermometer th, displayer d) {
  	_th = th;  _d = d; 
  	}
  public void operator() {
  	_d.put( _th.get() );
  	process();
  	}
  
  thermometer _th;
  displayer _d;
  };

slide: The show class

Activating a show event instance results in retrieving a value from the thermometer, putting that value on display and activating the events associated with this event.

The installation

The next step we must take is to install the application, that is to create the objects comprising the functional behavior of the system, the user interface objects and (finally) the various event objects.

  thermometer c = new centigrade();
  thermometer f = new fahrenheit();
  
  displayer cd = new displayer("centigrade");
  displayer fd = new displayer("fahrenheit");
  
  prompter cp = new prompter("enter centigrade value");
  prompter fp = new prompter("enter fahrenheit value");
  
  show sc = new show(c,cd);
  show sf = new show(f,fd);
  
  update uc = new update(c,cp);
  update uf = new update(f,fp);

slide: Installing the objects

Having created the objects, we are almost done. The most important and perhaps difficult part is to define the appropriate dependencies between the respective event objects.

  uc.dependent(sc);
  uc.dependent(sf);
  uf.dependent(sc);
  uf.dependent(sf);

slide: Assigning dependencies

As shown above, we declare the event of showing the value of the centigrade thermometer (and also of the fahrenheit thermometer) to be dependent upon the event of updating the value of the centigrade thermometer. And we repeat this declaration for the event of updating the value of the fahrenheit thermometer. We may now allow the user the choice between updating the centigrade or fahrenheit thermometer temperature value, for example by inserting these events in a menu, as indicated below

  menu.insert(uc);
  menu.insert(uf);

The reader is urged to do some mental processing to check that updating the value of one thermometer actually results in changing the value displayed for the other thermometer as well.

Discussion

Organizing interactions with the user (and the other components of the system as well) by means of events provides a powerful way in which to control the consequences of one particular (kind of) interaction. The advantage of such an approach is that the repertoire of possible interactions can easily be extended or modified without affecting the other parts of the system (the parts realizing the functional behavior of the system and the particularities of the user interface). From the perspective of design, it is a good alternative for defining {\em behavioral compositions} (and its corresponding protocol of interaction) in a more or less formal way. See also section Cooperation.

[2] - [up] [top] - [I] [II] [III] [IV] - [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] - [A] [R]

Hush Online Technology

hush@cs.vu.nl
12/29/99