Design Patterns

CHAPTER 15 ■ THE OBSERVER PATTERN 223
When Should the Observer Pattern Be Used?
The observer pattern should be used in situations where you want to abstract human behavior
from application behavior. It’s best not to implement something that is tied to user interaction and
originates from the browser, such as basic DOM events like click, mouseover, or keypress. None of
these events are useful pieces of information to an implementer who simply wants to know when
an animation begins, or when a word is spelled incorrectly in a spell-check application.
Let’s say for example that when a user clicks a tab in a navigation system, a menu with more
information about the tab is toggled. Granted, you could simply just listen for the click event, but
this requires knowing which element to listen for. There is another downside: you’ve now tied
your implementation directly to the click event. Instead of listening for the click event, it would
be better to simply create an onTabChange observable object and allow observers to be notified
when the particular event occurs. Since these tabs could in fact be toggled on mouseover or even
on focus, this is something that the observable object would take care of for you.
Benefits of the Observer Pattern
The observer pattern is basically a great way to maintain your action-based applications in
large architectures. In any given application you may have tens, hundreds, or even thousands
of events happening sporadically throughout a browser session. Furthermore, you can cut
back on event attachment and allow your observable objects to handle the actions for you
through one event listener and delegate the information to all its subscribers, thus reducing
memory and speeding up interaction performance. This way you don’t have to constantly add
new listeners to the same elements, which can become costly and unmaintainable.
Drawbacks of the Observer Pattern
One downside to using this particular observer interface is the cost in load time when setting
up the observable objects. You can mitigate this by using a technique called lazy loading,
which basically allows you to put off instantiating new observable objects until delivery time.
This way, subscribers can begin subscribing to an event that has yet to be created, avoiding
slowing down the initial load time of the application.
Summary
The observer pattern is a great way to abstract your applications. You can broadcast events and
allow any developer to take advantage of subscribing to those events without ever having to dig into
the other developers’ implementation code. Five people can subscribe to the same event, and five
separate events can all be delivered to the same subscriber. In an interaction environment such as
a browser, this is ideal. As newer, larger web applications are being built, adding observables into
your code base is a great way to keep your code maintainable and squeaky clean. They discourage
third-party developers and coworkers from digging into the guts of your application and possibly
messing things up. Impress your friends and managers by putting the observer into practice.
In the publisher utility, we developed a “push” system where the publishers broadcast an
event by pushing data to each of their subscribers. Try seeing if you can write a utility that allows
each subscriber to “pull” data from each of its publishers. Hint: You can try starting with a pull
function as a subscriber method that takes in a Publisher object as an argument.