The Observer Pattern
Tags: architecture, design, php, oop
Published: 2021-10-30 15:51:10

>**The Observer Pattern defines a one-to-many dependency between objects, so that when one object change state, all of its depedents are notified and updated automatically.**

When we talk about the observer pattern you can think of a newspaper and its subscribers, or an application that has to send notifications to their users. In both examples we can define each actor as **subject**(i.e: newspaper) and **observers**(i.e: subscribers).

Let's take for example an e-commerce platform, so when a user makes a purchase they receive a notification about the order. For example, I can go to my settings and check the checkboxes to receive a notification via Email, SMS and Phone Call. So, when I make a purchase, an order is created and then I receive a notification for each channel.

![One-to-many Relationship](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tlynrkphzzec1fp8fssq.jpeg)

If we see the image above, we can see that the relationship between the **subject** and the **observers** is the **one-to-many** relationship that we defined earlier.

The subject is the object that contains the **state**, and the observers use that state, so when the data changes in the subject (the order) the observers are updated.

Now that we understand the definition of the Observer Pattern we can take a look at the class diagram.

![Class diagram](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7qig55ilt7ufqmtficp1.png)

##Explaining the class diagram

The Observer pattern class diagram tell us that we need to have two **interfaces** (when we say **interface** we are referring to a contract, not a specific interface type, we can define either an abstract class or an interface type). One interface defines the methods that any subject needs to implement, and the other interface defines the methods that observers need to implement. 

Also, the Subject interface Has-A (Filled arrow) observer interface. This means that the subject needs to have the observers list.

Finally, we have our concrete classes that implements our interfaces, so we have the **ConcreteSubject** and the **ConcreteObserver** (There could be many **ConcreteObserver**)


##Applying the class diagram

So, in the case of our example of the order and the notification channels we can have the following class diagram.

![Concrete observer pattern](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tdu8jvkik06lr4148i9c.png)

##Benefits of this pattern

The Observer pattern provides an object design where subjects and observers are loosely coupled. 

###Why? 

* Because subject doesn’t depend on concrete classes but interfaces.

* The only thing subject knows about an  observer is that it implements an interface (The observer interface).

* We don’t need to modify the subject to add new types of observers.

##Variations

This pattern can have some variations, for example:

* The way we register the observers (each observer could register themself via constructor or we could have an array to register all observers to the subject).

* The way we get the data from the subject (subject can push the data to the observer or the observer can pull the data from the subject).

In conclusion, the whole idea of this pattern is to communicate a state to a group of objects in a loosely coupled way.


##Code implementation

[Observer Pattern](https://github.com/bakle/Design-Patterns/tree/main/src/ObserverPattern)


**Follow me on:** [Twitter](https://twitter.com/Bashir_Akle)