The Observer Problem

By Kenyon Geetings

While certainly not the most common design pattern, the observer pattern has revolutionized the way that our online world works today, and is the basis for some of Java UI’s core keyboard and mouse event listener components. In order to understand what the observer pattern does, one must first understand what design patterns are. Design patterns attempt to offer a general solution to common problems in software development, and allow developers to follow a guideline of best practices that intend to keep code easily maintainable and loosely coupled. With that in mind, we can now begin to tackle the problem that the observer pattern attempts to resolve, learn more about its structure, and examine a real world example of this pattern being applied.

Before we learn how the observer pattern solves some problems, it is crucial to first understand the terminology and basic idea behind this pattern. The observer pattern is also frequently referred to as the publish-subscribe pattern, which does an arguably better job of explaining how this pattern works by noting the relationship between our classes. The observer pattern defines a one-to-many dependency. Essentially this means we have one subject class, also called the publisher, and many many observer classes, which are the subscribers. While this will be explained in more detail later, the publisher class is not really dependent on the subscribers, but the subscribers are dependent on the publisher. Because we have two classes communicating with each other, the observer pattern falls under the behavioral pattern type, which concerns the interaction and responsibility of objects that are loosely coupled.

The observer pattern attempts to solve several problems, the most important of which is that the classes are tightly coupled. What this means is that one class is dependent on another class in order to function correctly. With the observer pattern, this is solved by one class being dependent on an interface. This allows the main class to be loosely coupled with the class that is dependent on the interface, and thus as briefly explained before, makes the main publisher class easier to modify and update. One other problem we see is that the observers might get more data than they require, which is rectified in the observer pattern by making the observer only store what it needs and nothing more.

To further explain how this pattern works, let’s take a look at the UML for the general structure of this pattern. As we can see, the observer pattern all revolves around the observer interface class. This observer interface, or abstract class, defines the operations to be used to notify the observers (ViewObserverOne and ViewObserverTwo). These view observers implement the observer interface, and only care about their own state (which is only what they are subscribed to). We can also see the subject interface, or abstract class, which defines the operations of the observers to the client. This class is what lets us create and delete observers, as well as what gives us the ability to notify the observers of an update.

Now that we have the general structure of the pattern, we can take a more in depth look at a real example where this pattern might be used. This example is of a stock ticker where devices are subscribed to different stocks, and when the stocks are updated, the devices’ states are also updated and notified with only their subscribed stocks. The subject and observer interfaces follow the same design as the general structure’s equivalent classes. The StockGrabber class is what implements the Subject and is what is used to update all the observers, while the StockObserver represents each observer that is monitoring changes in the subject. The GrabStocks is not terribly crucial to the observer pattern, but this is where our main is run from, and where we actually handle all the observers in our project.

In conclusion, the observer pattern allows us to send information to several observers without the need for the subject class to keep track of each observer’s subscriptions. This allows for a more loosely coupled implementation, and subsequently means that making modifications and maintaining the subject class is easier.