Overview #

In this tutorial we work on the improvement of the basic observer pattern from Part 1 of this tutorial series.

Basic Observer #

Let’s have a look at our basic observer model.

In the current model we achieve to decouple the existence of the NewsAgency class from the NewsChannel class to a limited extent. Upfront, the NewsAgency does not know

1. which NewsChannel instance to notify and
2. how many NewsChannel instances are to be notified

This concept is also referred to as decoupling.

However, lets assume we have a NewsPaper that also wants to be notified by the NewsAgency. Currently, the NewsAgency only allows NewsChannel to subscribe.

Abstract Observer #

The solution for this problem is a generalization of the observer pattern. We define abstract classes that implement the logic of the observer pattern and derive NewsAgency, NewsChannel, and NewsPaper from these classes.

NewsAgency now IS an Observable and NewsChannel and NewsPaper IS an Observer. The subscribe and unsubscribe methods of Observable accept instances of Observer. Because NewsChannel and NewsPaper IS an Observer and NewsAgency IS an Observable, instances of both classes can now be subscribed to the Observable NewsAgency.

This allows to have following instantiations:

With this solution, NewsChannel and NewsPaper can subscribe to NewsAgency.

Why Use the Observer Pattern? #

• Decoupling: It promotes loose coupling between the observable and the observers. The observable does not need to know the details of the observers, only that they implement a specific interface. This makes the system more modular and easier to maintain.

• Dynamic Relationships: Observers can be added or removed at runtime, allowing for dynamic changes in the relationships between objects. This is useful in applications where the state of an object needs to be reflected across multiple views or components.

• Event Handling: It is ideal for implementing distributed event-handling systems. When an event occurs, the observable notifies all registered observers, which can then handle the event in their own way.

• Consistency: It ensures that all observers are kept in sync with the observable’s state. This is particularly important in applications where multiple components need to display or react to the same data.

• Reusability: By defining a standard way for objects to communicate changes, the Observer Pattern can be reused across different parts of an application or even in different projects.

Summary #

Overall, the Observer Pattern is a powerful tool for managing dependencies and ensuring that changes in one part of a system are propagated to all interested parties in a clean and efficient manner. By decoupling the observable and observers, it promotes modularity and maintainability. The pattern allows for dynamic relationships, making it easy to add or remove observers at runtime. It is particularly useful for event handling and maintaining consistency across multiple components. Additionally, the Observer Pattern enhances reusability by providing a standard way for objects to communicate changes.

In this section, we explored the basic observer model and its limitations, followed by an improved version using abstract classes. This generalization allows different types of observers to subscribe to the observable, demonstrating the flexibility and power of the Observer Pattern.