The Design Pattern Observer: a powerful notification system

In the development of your applications, you will often need your application to be able to react to events flexibly. For example, let's say you want to notify multiple systems when certain actions occur (like user registration). This is where the Pattern Observer comes in. This pattern allows you to establish a relationship between objects, so that when the state of one changes, all the others are automatically informed and updated.

Symfony already effectively implements this pattern thanks to the Event Dispatcher, which makes it very practical and powerful to use in your projects.

What is the Pattern Observer?

The Pattern Observer allows you to define a relationship between the observed subject and one or more observers. When a change of state occurs on the observed object, all observers are notified so that they can react accordingly.

Here’s how it works:

• ? Subject (Observable): The main object that changes state.
• ? Observers: Objects that react to changes in the observable.

Example

Let's imagine you have a site where a user can register. With each registration, you want to send a welcome email, add the user to a newsletter list and inform an analytics system.

Rather than rigidly coding everything in one place, you can delegate these tasks to different observers who will be informed as soon as the "registered user" event is triggered.

Implementing the Pattern Observer in Symfony

In Symfony, you will use the Event Dispatcher to set up the Pattern Observer. This will allow you to organize the code neatly and make it extensible without modifying the basic logic.

Step 1️⃣: Declare the Event

We will start by creating an event which will be dispatched when a user registers. The latter will contain the user's information.

Step 2️⃣: Dispatch the Event

Now, in your controller or service, you will dispatch this event when a user registers.

Step 3️⃣: Create Observers (Listeners)

Next, you will have to create the observers, which will be called each time the registration event is dispatched. Here, you have the example where we send an email and we add the user to a newsletter list.

Observer 1: Send a welcome email

Watcher 2: Add user to a newsletter list

Step 4️⃣: Configuring Observers

You must now register the listeners in the configuration so that they listen to the user.registered event.

In config/services.yaml, add observers as services:

ℹ️ Since version 5.3 of Symfony, you can use PHP attributes to configure services and event listeners. This is a more modern approach that allows you to declare events directly in classes, instead of using the services.yaml file.
You can therefore use the #[AsEventListener] attribute directly on your listener method.

I'll show you how to adapt the two observers with attributes (so no need for special config in config/services.yaml? :

Observer 1

Observer 2

Little explanation

• The #[AsEventListener] attribute indicates that the method is a listener for a specific event.
• The first argument of the attribute is the name of the event that the observer is listening for (UserRegisteredEvent::NAME).
• And finally, the method parameter specifies the method of the class that will be executed when the event is triggered (in our case, onUserRegistered). ?

Step 5️⃣: Test the implementation

When you register a user with the RegistrationController, the event is dispatched and Symfony automatically calls the corresponding observers. The email is sent, and the user is added to the newsletter list without these actions/logic being mixed with your business code.

Why Use the Pattern Observer?

Because it's an essential! It will allow your application to be:

1. More flexible: you can add or modify observers without touching your main code. Just add a listener!
2. Less coupled: the different parts of your app are not closely linked. For example, sending emails and adding to the newsletter are not coded directly in the registration controller.
3. More scalable: this pattern makes it easy to react to events that could involve several systems or services (notifications, analytics, sending, etc.).

Bonus: The link with DDD (Domain-Driven Design)

The Pattern Observer often finds its place in architectures based on DDD (Domain-Driven Design), where events are key elements (Domain Events). These events allow different parts of the system to react, often outside the main domain. But that’s a discussion for a future full article on DDD!

The above is the detailed content of The Design Pattern Observer: a powerful notification system. For more information, please follow other related articles on the PHP Chinese website!