Question observer design pattern .. more

Responding to Ma740988...

>> [Subject]
>> | *
>> |
>> | R1
>> |
>> | notifies
>> | 1
>> [Registrar]
>> | 1
>> | registers with
>> |
>> | R2
>> |
>> | forwards messages to
>> | *
>>[Listener]
>>
>> IOW, the Registrar is the Observer from the pattern but it is limited to
>> providing redirection via a mapping between Subject messages and the
>> real Listeners who actually care about those messages. The Listeners are
>> then fully decoupled from Subject. Note that in this scheme the R2
>> registration can be instantiated by any object that understands the
>> context, not necessarily the Listener (though that is most common). Also
>> note that the registration can be based on the message ID rather than
>> who actually generates the message. (Obviously the Subject needs to
>> "register" its messages with the Registrar as well.)
>>
> Are you registering R1, R2s or are you registering a listener? I'm
> trying to put together source (only way I sometimes envision these
> patterns) code based on your response which I think would suite nicely
> - in my case.

I'm a translationist so I never deal with 3GL source code. B-)

There are actually two registrations. Subject needs to register the
message identifier for the R1 association. However, this is usually
implied. Subject just sends the message to Registrar who checks the
message identifier to see if anyone is registered to listen to that
message. Depending on the problem, Registrar can ignore the message,
generate an exception, or take some recovery action if there are no
Listeners registered for the message.

[Note that a message ID comes for free with true event based processing
because each event must have an identifier to be looked up in an STT for
an object state machine. But in a synchronous application the message ID
can simply by the Registrar interface method signature, such as
processAbort(...), processreset(...), etc..]

This only becomes an issue in a more elaborate situation where there are
multiple Subjects generating multiple messages. Then it may become
convenient for each Subject to register the messages it generates. Even
then it is usually only important if one wants to make sure that only
certain Subjects can send certain messages.

The other registration is for the Listeners. This one is always
explicitly managed. Essentially one is instantiating the R2 association
for each listener. If there is only one message anyone cares about, this
is trivial because Registrar simply forwards the message to every object
in the R2 collection and each Listener is registered by adding its
reference to the R2 collection.

The only implementation complexity lies in getting around static typing
in the OOPL when the listeners in the collection are from different
classes. [A full code generator would employ Object* references in C++
or something similar because other mechanisms would ensure that no
Listener would be registered who could not accept the message.]

If there is more than one message to dispatch, then the Registrar
implementation gets more complicated because it has to match both
{message ID, Listener reference}. In that case Registrar starts to look
like an association class for a *:* association. There are various ways
to do that (e.g., internally managing a separate R2 collection for each
message ID) and the best way will probably depend on nonfunctional
requirements like performance/size.

In any case, in practice Registrar usually has an addListener(...)
interface method that manages the R2 association for purposes of
registration. That way the implementation mechanics are completely hidden.

BTW, it is good practice to always make the arguments to addListener be
{message ID, Listener reference}, even when there is only one subject
and one message. That allows one to change one's mind later about the
number of Subjects and messages without touching existing Listeners (or
the objects that do the actual registering). IOW, it makes Registrar
more context-independent and, consequently, more reusable.

Bottom line: there is a lot of wiggle room in the actual implementation
of the pattern to accommodate varying degrees of complexity in the
actual problem. But those design decisions tend to fall out in a
straight forward manner so long as the one has a good grasp on the
pattern's Big Picture of {condition raised -> announcement message ->
someone who cares} and one focuses on decoupling who raised the
condition from who cares about the condition by inserting a context
mapper in the middle.


--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH