Real-World Observer Pattern in CF?

[insuractive]

I'm putting together some course material for my office mates on design patterns in ColdFusion. I'm having a hard time coming up with a realistic real-world example of what situations would be a good candidate to be solved by an observer pattern in a CF web application.  There are certainly many examples of how to implement the pattern in CF, which is great, except I don't really find many of the scenarios that the examples are based off to make sense in a web application environment  - many of them are based off of Java examples where references to the observer/observable objects are maintained for the life (session) of the application. 

In a CF web application, this seems like it would only make sense if you were dealing with Singletons for both the observer and observable objects in order for their references to exist outside of the scope of a single page load.  On the other hand, I'm having a conceptual block coming up with a compelling problem on why you would need an observer pattern in the context of a single CF page.

I would love to hear of any real world examples that other CF devs have come into contact with.  I'm sure I could probably point to something like LogBox as an example of the behavior, but I was hoping to have a very simple example that I could use put some code in front of my developers.

Thanks in advance!

-Michael

[Dave Watts]

In a lot of web applications, you do keep around objects for the life of the session or application. Any J2EE examples you find will be applicable in CF as well. Any time you want to have a publish-subscribe connection - well, that covers a lot of ground! I do this sort of thing with Flex or AJAX-based client controls and a CF back-end, although those examples might not be the simplest to describe.

Dave Watts, CTO, Fig Leaf Software

[BKBK · Accepted solution]

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.

[insuractive]

BKBK - I really appreciate the time it took to craft such a thorough response!  Your description of the Observer model is in line with my current understanding of the concept.  The DirectoryWatcher Gateway example is EXACTLY what I needed as a real-world example of an observer model that could be implemented in CF.

I was having a conceptual problem thinking about how a subject object could maintain both state as well as a collection of registered observers through the life of the application.  I was thinking Singleton might come into play since you could define a central, shared object that could maintain state and observer subscriptions through multiple page requests. Your points, though, about coupling are excellent.

[facepalm] I can't believe it didn't occur to me that a CF object could store state and observers in a data store (DB, log, etc).  The DirectoryWatcher event gateway demonstrates this perfectly.  It queries a directory occasionally, compares directory state vs internal state and when there is a change, it calls the appopriate method of the registered observer objects.

Thanks again BKBK!