10.3.1 The Signaler Pattern Specification

The Signaler pattern lets signals live outside the object about which they are signaling.

Sometimes signals for objects are hard to use. For example, if FirstObject wants to connect to a signal emitted by SecondObject, but SecondObject does not exist yet, creating the connection is a problem. We have created the Signaler pattern to solve this problem. Now, FirstObject connects to signals emitted by SecondObjectSignaler, a Rooted Singleton. Then SecondObject has the SecondObjectSignal emit the signals causing FirstObject to get signalled.

Here is a simple example:

// Class that wants to let others know about a change in speed.
class Foo
{
public:
   void setSpeed(double s) 
   { 
      mySpeed = s; 
      FooSignaler::instance(
         myDisplayEngine).signal_speedChanged(this,mySpeed);
   }
protected:
   DtDe myDisplayEngine;
};
// Class that emits signal_speedChanged;
class FooSignaler
{
public: 
   // Lazily create a global instance rooted off a Display Engine
   static FooSignaler& instance(DtDe& displayEngine)
   {
      FooSignaler* singleton = dynamic_cast<FooSignaler*>(
         displayEngine.findInstance("FooSignaler"));
      if(!singleton)
      {
         singleton = new FooSignaler();
         displayEngine.registerInstance("FooSignaler",singleton);
      }
      return *singleton; 
   }
   // Signal to emit.
   signal < void (Foo*, double) >  signal_speedChanged;
};

Now, an interested party can register with the FooSignaler before an instance of the Foo object actually exists:

FooSignaler::instance(myDisplayEngine).signal_speedChanged.connect(
   boost::bind(&InterestedPartyClass::onSpeedChanged,
   &insterestedPartyClassInstance, _1)));

The signaler is lazily created and the InterestedPartyClass gets signaled whenever an instance of Foo comes into existence and setSpeed() is called on it.

10.3.1 The Signaler Pattern Specification

The Signaler pattern has the following requirements and behavior:

The Signaler pattern involves two classes: the subject class, which wants to let others know when something has changed, and a signaler class, the object that parties interested in updates register with.
The signaler class should not have a public constructor.
The signaler class should provide a static instance accessor to easily get the signaler instance from the root object.
The signaler class must be explicitly registered with the root object. This is usually done through lazy creation.
The lifetime of a signaler is linked to the lifetime of the root object.
The subject class uses the signaler class to emit signals when things in the subject class change.
Interested parties connect to the signals in the signaler to find out about changes in the subject class.

[<< The Rooted Singleton Pattern] [Home] [Top of Page] [The Factory Pattern >>]

Table of Contents

10.3.1 The Signaler Pattern Specification