From: Ruben <Ruben.Vandeginste@...>
Date: 2004-05-27T08:10:27+09:00
Subject: Re: Design Question


At Thu, 27 May 2004 05:12:33 +0900,
Zach Dennis wrote:
> 
> Let me better define my Status object. It would be used to handle displaying
> messages to the user in a universal format in a GUI instead of having error
> that should be reported to the user going like:
> [snip]
> I have been reading and rereadin the Design Patterns book and the
> Refactoring book published by Addison Wesley and I am trying to properly
> patterns where they "make sense". Does my definition of the staus object fit
> the need for a Singleton?
> 
> I am thinking yes, but looking for more input. Thanks for responding.

The way i look at what you wanna do, is that you wanna inform the user
that 'something' happened. This is more general than what you
describe. I would probably solve this with something related to
Observer-Observable.  I would define an 'EventManager', which would be
a Singleton. (there should be only 1 EventManager, and it should be
accessible from anywhere) An object that wants to be notified of a
certain 'Event', should subscribe itself for those events in the
EventManager. Every time a certain Event happens, the object that
causes the Event, should 'fire' the Event with the EventManager and
the EventManager will notify all objects that subscribed for this
Event.

In your case... if an error happens somewhere, then the EventManager
should be warned about it and the Eventmanager would then notify the
Textfield (or every object that is interested in that particular
error) that has to show the error.

(Something i like in Ruby, is that an object that wants to be
registered for a certain event in the eventmanager, can actually just
'give' the eventmanager the code that should be executed when the
event is triggered as an extra parameter in the 'subscribe'-call. I
wonder whether there are people who use something like this.)

The difference with your StatusObject is that this is more general,
you allow any kind of object that is interested in the event to
register itself for it. Also, the EventManager doesn't have to know
anything about the objects that want to be notified and in this way
you won't create any dependencies in your 'domain' on the 'GUI'.

In your case, you would probably have an 'ErrorEvent' which contains
the number of the error and the description of the error. Maybe also a
(probably Singleton) class that would build the ErrorEvents given an
error number. Then the EventManager would call something like
"triggered_error(myErrorEvent)" on the objects that subscribed for
ErrorEvents in the EventManager.

Ruben