Some years ago when I, too, was grappling with design patterns, I found some useful material from Microsoft's MSDN. One of them, the paper by Doug Purdy and Jeffrey Richter on the Observer Pattern, is quite good and contains a stock-market example.
I don't see how you arrived at singletons for observers. More on that in a moment. The essence of the Observer Pattern goes beyond the programming language, syntax or implementation details. Everything you need to know is in the traditional patterns diagram (which I have reproduced here from the Wikipedia on the Observer Pattern).
In fact, the diagram itself is quite suggestive, and can help you come up with examples of your own. There are 2 main roles, the Observer and the Subject. There is as little dependency as possible (that is, loose coupling) between them. This enables either to change their internal mechanisms without affecting the other.
At its most basic, with just 2 roles, the Observer observes the Subject. The Subject in turn keeps watch on a dynamic resource which the Observer wishes to know about.
In most practical applications, there is more than one observer interested in the dynamic resource. The Subject has a responsibility to notify each observer of the resource, or of any change. To be able to do so, it maintains a list of the observers. Each Observer has the responsibility to get notified by the Subject. That's it. Any system that works in this way, is said to apply the Observer Pattern.
The commonest practical example is a news publisher and the subscribers. The publisher is the Subject, the subscriber the Observer and the news the dynamic resource. In fact, much like Hoover became a synonym for vacuum-cleaners, so too has Publisher-Subscriber become a synonym for the Observer Pattern.
The necessity of loose coupling between Observer and Subject means neither of them should use global or shared variables. These variables create the tightest form of coupling possible. Let's then return to the question of whether or not to implement Observer by means of a singleton. I wouldn't. Absolutely not. A singleton is an application-scoped, hence shared, variable and would therefore increase coupling.
To keep coupling loose, it is usually recommended to implement the Observer and the Subject as an interface. The classes representing the actual, concrete observers and subject would then be implementers of the respective interfaces. Each such concrete class could change its internal structure radically, and the outside world wouldn't notice. That is because the respective interface for Observer and Subject remains intact.
Now to the puzzle of coming up a practical example of the Observer Pattern in the context of a single ColdFusion page. In the Observer Pattern, the subject is by necessity a listener object, listening in on some dynamic resource. Hence, the ColdFusion page representing the subject will have to be a listener CFC. There is already an in-built example in ColdFusion. It is the DirectoryWatcher event gateway. Use inheritance to adapt the CFC to include functionality to maintain a list of observers in the database. Include, for example, queries to notify observers by e-mail whenever a change occurs within a directory.
AdChoices