Introduction 3

In the last demo, you implemented the Factory pattern. You saw that you can use it to hide the implementation details of objects that share a base type. It abstracts the setup and construction processes that the objects need before you can use them in your system. It also hides their types; you’ll receive them as instances of their base types.

The next and last pattern you’ll learn in this lesson is the Observer pattern. It’s an interesting pattern that’s common, but not always obvious. Properly understanding this pattern can help you implement proper, simple and frequent UI updates.

Before going into the pattern’s details, you’ll need to understand the problem it solves.

Imagine that you have a bunch of modules that all share a common data source. That data source receives updates frequently, and the other modules need to react to the individual changes occurring in the data source. Additionally, the number of modules that will react to the changes varies.

One way to handle this is to set up a system where, whenever the source of the changes applies those changes to the data source, you also notify the other modules that the data has changed. But that can get very messy quickly.

Another way is to use the data source itself to notify those modules that changes have occurred. However, this implies the data source must recognize the modules to notify them, even as the modules are aware of the data source. This mutual recognition can become tangled. Without proper abstraction, it might disrupt your dependencies or make your implementation more complex.

The Observer pattern provides a common design that solves this problem. It gives you a specification to implement to allow different modules to make themselves known to data sources so they can receive updates on them. And when they’re done, they remove themselves and stop receiving updates.

Think of it like a newsletter. The person creating the newsletter doesn’t know who’s on the mailing list; they just send their email to the list as a whole. Another system or person is responsible for maintaining the people present on that mailing list — the subscribers — and provides a mechanism that they can ask to stop receiving updates, or unsubscribe.

For your contacts program, you want the contacts book to receive an update whenever a contact gets updates.

The Observer pattern has a two-part specification:

1. The subject: The entity that gets updated. In this case, it’s the contact card.
2. The observer: The entity that wants to know about updates to the subject(s) it’s interested in. In this case, the observer is the contacts book.

The observer is nothing more than a protocol or interface that defines a method that informs it when a subject has been updated. The subject defines four things.

First, it defines a

1. A list of observers.
2. A method to add an observer to the list.
3. A method to remove an observer from the list.
4. A method to announce to all the observers that this subject has been updated.