Imagine that you have a favorite blog. Every day you visit it multiple times per day to check for new blog posts. After a while, you get fed up with this routine. There must be a better way you think to yourself. The first solution that crosses your mind is to write a script to check the blog for new posts every fraction of a second. But upon further consideration, you realize most sites would not appreciate this barrage of requests, and would block your IP address. To avoid this, you instead write a script to check the blog for new posts once per hour. But to your disappointment, this means that you're now missing out on blog posts that provide live changes, such as real time posts about your favorite TV show. A better solution to this problem is for the blog to notify you every time a new post is added. You would subscribe to the blog, every time a new post was published, the blog would notify each subscriber, including you. This way, you would be notified of the new content when it is created, rather than having to pull for this information at some interval. The subject in our example, the blog, would keep a list of observers. In this example, we might think of these observers as subscribers to the blog. The observers rely on the blog to inform them of any changes to the state of the blog such as, when a new blog post is added. Before we formalize this design pattern, let's explore how we could apply this idea to our example. First, we'll have a Subject superclass that defines three methods, allow a new observer to subscribe, allow a current observer to unsubscribe, and notify all observers about a new blog post. This superclass would also have an attribute to keep track of all the observers, and will make an observer interface with methods that an observer can be notified to update itself. Next, the blog Class will be a subclass of the Subject superclass, and the Subscriber Class will implement the observer interface. These design elements are essential to forming a Subject and Observer relationship. For example, for the blog and subscriber. In a sequence diagram that applies an observer pattern, there are two major rules, the Subject and the Observer. Which in our example are played by a blog and a Subscriber. In order to form the Subject and Observer relationship, a Subscriber must subscribe to the blog. Next, the blog needs to be able to notify its subscribers that a change has happened. It's the job of the notify function to keep all of the subscribers consistent. This method is only called when the blog has a change, ready for its subscribers to know about. After the blog has a change, it's time for the blog to notify its subscribers through an update call, and the subscribers to get the state of the blog through a get state call. It's up to the blog to make sure its subscribers get the latest information. If the subscriber does not end up enjoying the content of the blog, they would need a way to unsubscribe. That is the last call in the sequence diagram. It originates from the subscriber, and lets the blog know the subscriber should be removed from its list of subscribers. This is the core behavior for the Observer Design Pattern, an essential for our subscriber to be able to subscribe to a blog they like. Now that we've applied the observer pattern to a specific example, let's take a look at how this idea can be abstracted into a design pattern, as given by the following UML diagram. In this UML class diagram, the subject superclass has three methods, register observer, unregister observer, and notify. These are all essential for a subject to relate to its observers. Specifically, the blog subclass of subject would inherit these methods to subscribe, unsubscribe and notify its subscribers. The observer interface only has the update method. An observer must always have some way to update itself, without the ability to be told to update an observer wouldn't be informed of changes in the subject. The Subscriber class implements the observer interface, providing the body of an update method so a subscriber can get what changed in the blog. Note that a subject may have zero or more observers registered to it at any given time. Now, it's time to take a look at some Java code for the Observer pattern. Let's see what the code for the subject superclass looks like. The register observer method adds an observer to the list of observers. The unregister observer method removes an observer in the list, and the notify method calls an update upon each observer on the list. Next, the blog class is a subclass of subject, which will inherit the register observer, unregister observer and notify methods and have the other responsibilities of managing a blog and posting messages. Now that I've gone over the subject superclass, let's take a look at the observer interface. The observer interface makes sure all observer objects behave the same way. Observer classes only need to implement a single method, update. The update method is called by the subject. The subject makes sure when a change happens, all its observers are notified to update themselves. More specifically, for our example, we have a class subscriber that implements the observer interface. This update method is called, "when the blog notifies the subscriber of a change.". The observer design pattern can save you a lot of time when you're implementing your system. If you know that you have many objects that rely on the state of one, the value of the observer pattern becomes more pronounced. Instead of managing all the observer objects individually, you can have your subject manage them and make sure the observers are updating themselves as needed. There are many different ways and situations you can apply the observer design pattern. As a behavioral pattern, it makes it easy to distribute and handle notifications of changes across systems, in a manageable and controlled way.
