Professional PHP Design Patterns

13.1. Problem and Solution

The clearest example of the Observer Design Pattern is the plugin system. Because a good portion of the applications that I worked on were managed by a core team of developers, I didn't see many reasons to create a plugin-based code base. In fact, I was quite reluctant to even explore the Observer pattern further. But the plugin system is only the most common example of the Observer Design Pattern in use. There are many other ways to implement it.

The core concept of the Observer Design Pattern solves a very common problem. Software applications continually need new features to stay viable. But, how can additional functionality be added to the application without having to completely refactor some of the core objects? The Observer Design Pattern lays out the blueprint to solve this issue from the object's initial creation.

First, it's important to understand that the Observer Design Pattern is based around state changes. A state change is simply an object being transformed from one thing to another. This could be very simple such as an internal method being called that alters the object's properties. It could also be a more involved process such as a complete logic path; for example, balancing an inventory object after selling some merchandise based on another object. In either example, state changes are happening to the object.

The core object that is based on the Observer Design Pattern is responsible for communicating these state changes to other ...