Design Pattern Observer: 強力な通知システム

アプリケーションの開発では、アプリケーションがイベントに柔軟に反応できることが必要になることがよくあります。たとえば、特定のアクション (ユーザー登録など) が発生したときに複数のシステムに通知したいとします。ここで、パターン オブザーバーが登場します。このパターンを使用すると、オブジェクト間の関係を確立できるため、1 つの状態が変化すると、他のすべてのオブジェクトが自動的に通知され、更新されます。

Symfony はイベント ディスパッチャーのおかげでこのパターンをすでに効果的に実装しているため、プロジェクトで使用するのに非常に実用的で強力です。

パターンオブザーバーとは何ですか?

パターン オブザーバーを使用すると、観察対象と 1 人以上のオブザーバーの間の関係を定義できます。観察対象のオブジェクトで状態の変化が発生すると、すべての観察者が通知を受けて、それに応じて対応できるようになります。

その仕組みは次のとおりです:

• ? Subject (Observable): 状態を変更する主要なオブジェクト。
• ?オブザーバー: オブザーバブルの変化に反応するオブジェクト。

例

ユーザーが登録できるサイトがあると想像してみましょう。登録するたびに、ウェルカム メールを送信し、ユーザーをニュースレター リストに追加し、分析システムに通知する必要があります。

すべてを 1 か所で厳密にコーディングするのではなく、これらのタスクをさまざまなオブザーバーに委任して、「登録ユーザー」イベントがトリガーされるとすぐに通知を受けることができます。

Symfony でのパターン オブザーバーの実装

Symfony では、イベント ディスパッチャーを使用してパターン オブザーバーをセットアップします。これにより、コードをきちんと整理し、基本的なロジックを変更せずに拡張可能にすることができます。

ステップ 1️⃣: イベントを宣言する

まず、ユーザーの登録時に送出されるイベントを作成します。後者にはユーザーの情報が含まれます。

ステップ 2️⃣: イベントをディスパッチする

ここで、コントローラーまたはサービスで、ユーザーの登録時にこのイベントをディスパッチします。

ステップ 3️⃣: オブザーバー (リスナー) を作成する

次に、登録イベントが送出されるたびに呼び出されるオブザーバーを作成する必要があります。ここでは、電子メールを送信し、ユーザーをニュースレター リストに追加する例を示します。

オブザーバー 1: ウェルカム電子メールを送信する

Watcher 2: ユーザーをニュースレター リストに追加する

ステップ 4️⃣: オブザーバーの構成

次に、リスナーが user.registered イベントをリッスンできるように、設定にリスナーを登録する必要があります。

config/services.yaml で、オブザーバーをサービスとして追加します。

ℹ️ Symfony のバージョン 5.3 以降、PHP 属性を使用してサービスとイベント リスナーを設定できます。これは、services.yaml ファイルを使用する代わりに、クラス内でイベントを直接宣言できる、より新しいアプローチです。
したがって、リスナー メソッドで #[AsEventListener] 属性を直接使用できます。

2 つのオブザーバーを属性で調整する方法を示します (config/services.yaml で特別な設定は必要ありません? :

観察者1

観察者2

Petite explication

• L'attribut #[AsEventListener] indique que la méthode est un listener pour un événement spécifique.
• Le premier argument de l'attribut est le nom de l'événement que l'observateur écoute (UserRegisteredEvent::NAME).
• Et enfin, le paramètre method précise la méthode de la classe qui sera exécutée lorsque l'événement sera déclenché (dans notre cas, onUserRegistered). ?

Étape 5️⃣ : Tester l'implémentation

Lorsque tu enregistres un utilisateur avec le contrôleur RegistrationController, l'événement est dispatché et Symfony appelle automatiquement les observateurs correspondants. L'email est envoyé, et l'utilisateur est ajouté à la liste de newsletters sans que ces actions/logiques ne soient mélangées à ton code métier.

Pourquoi Utiliser le Pattern Observer ?

Parce que c'est un indispensable ! Il permettra à ton application d'être :

1. Plus flexible : tu peux ajouter ou modifier des observateurs sans toucher à ton code principal. Il suffit d'ajouter un listener !
2. Moins couplée : les différentes parties de ton appli ne sont pas étroitement liées. Par exemple, l'envoi d'emails et l'ajout à la newsletter ne sont pas codés directement dans le contrôleur d'inscription.
3. Plus scalable : ce pattern permet de réagir facilement à des événements qui pourraient impliquer plusieurs systèmes ou services (notifications, analytics, envois, etc.).

Bonus : Le lien avec le DDD (Domain-Driven Design)

Le Pattern Observer trouve souvent sa place dans les architectures basées sur le DDD (Domain-Driven Design), où les événements sont des éléments clés (Domain Events). Ces événements permettent de faire réagir différentes parties du système, souvent en dehors du domaine principal. Mais ça, c’est une discussion pour un prochain article complet sur le DDD !

以上がDesign Pattern Observer: 強力な通知システムの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。