In object-oriented architectures, the developer works hard to create a set of decoupled entities. In this way, entities can be tested, reused, and maintained without interfering with the whole system. Designing this kind of system brings a tricky side effect: maintaining consistency between related objects.
The first example of a pattern created to solve this issue was in the Smalltalk Model-View-Controller architecture. The user interface framework provided a way to keep UI elements separated from the actual object containing the data, and, at the same time, it provided a handy way to keep everything in sync.
The Observer pattern is one of the most famous design patterns discussed in the popular Design Patterns: Elements of Reusable Object-Oriented Software by The Gang of Four. It's a behavioral pattern and it provides a way to bind objects in a one-to-many dependency: when one object changes, all the objects depending on it are notified and updated automatically.
In this chapter, we are going to have an overview of the Observer pattern, how it's implemented and extended by RxJava, what an Observable is, and how Observables relate to Iterables.
Nowadays, the Observer pattern is one of the most common software design patterns on the scene. It's based on the concept of subject. A subject is a particular object that keeps a list of objects that want to be notified when the subject changes. These objects are called Observers and they expose a notification method that the subject invokes when its state changes.
In the previous chapter, we saw the spreadsheet example. Now we can expand the example, showing a more complex scenario. Let's think about a spreadsheet containing the accounting data. We could represent this data as a table, as a 3D-histogram, or as a pie chart. Every one of these representations will depend on the same set of data being displayed. Every one of these representations will be an Observer, depending on one single subject, maintaining all the information.
The 3D-histogram class, the pie chart class, the table class, and the class maintaining the data are perfectly decoupled: they can be used and reused independently, but they can work together too. The representation classes don't know each other, but they act like they do: they know where to find the information they need to show, and they know that they have to update their data representation the moment the data changes are notified.
The figure here depicts how the Subject/Observer relationship is a one-to-many relationship:
The previous figure shows that one single subject can serve three Observers. Obviously, there is no reason to limit the number of Observers: a subject could have an infinite number of Observers if necessary, and every one of them will be notified when the subject state changes.
The Observer pattern is the perfect fit for any of these scenarios:
- When your architecture has two entities, one depending on the other, and you want to keep them separated to change them or reuse them independently
- When a changing object has to notify an unknown amount of related objects about its own change
- When a changing object has to notify other objects without making assumptions about who these objects are