まず、オブザーバー パターンの概念を理解します。オブジェクトは、(別のオブジェクトであるオブザーバーが自身を登録できるようにする) Observable メソッドを追加することで、それ自体を変数にします。監視可能なオブジェクトが変化すると、登録されたオブザーバーにメッセージが送信されます。これらのオブザーバーは、この情報を使用して、監視可能なオブジェクトとは独立して操作を実行します。その結果、オブジェクトは理由を理解することなく相互に通信できるようになります。オブザーバー パターンはイベント システムです。つまり、このパターンにより、クラスが別のクラスの状態を監視できるようになり、監視しているクラスは通知を受け取り、対応するアクションを実行できます。コンポーネント間の密結合を回避する機能を備えています。
UML 構造図:
オブザーバーパターンによって解決される問題
開発プロセス中に、コードの一部を変更すると他の一連の変更が発生するという問題に多かれ少なかれ遭遇するはずです。この状況を完全に回避することは明らかに不可能ですが、他の部分への影響を最小限に抑えるように努める必要もあります。コンポーネントの依存関係、およびオブザーバー パターンはこの問題を解決します。
たとえば、次のコードを持つ post オブジェクトがあります:
リーリー上記は通常の投稿対象です。投稿数やアクセス数が増えると、当社のウェブサイトにセンシティブなコンテンツやスパム広告が含まれているという苦情の電話が頻繁に届きます。コンテンツのレビュー: 第一に、ユーザーのレビュー。ブラックリストに登録された一部のユーザーは投稿を禁止されるべきです。第二に、IP のレビュー。第三に、コンテンツ内のセンシティブな単語のレビューです。コードは次のようになります:
リーリーレビューする必要があるフィールドが増えるにつれて、addPost メソッドはますます長くなり、公開オブジェクトはシステムにしっかりと埋め込むことしかできなくなります。
オブザーバーパターンの実装
オブザーバー パターンの核心は、イベントが発生したことをサブジェクトが知っているときに、オブザーバーをサブジェクトから分離することですが、同時に、オブジェクト間の関係をハードコーディングしたくありません。サブジェクトとオブザーバーを変更するので、上記のコードをダウンロードします:
リーリー上記のコードを使用すると、監査ルールを簡単に追加できます。
SPLコード
オブザーバー パターンは非常に一般的で一般的に使用されるデザイン パターンであるため、SPL 拡張機能によって対応するクラスとメソッドがカプセル化されています。次のコードは、SPL によって提供される 3 つの要素 (SplObserver、SplSubject、SplObjectStorage) に基づいて実装されています。コード
リーリー最も重要なことは、この例ではいくつかのレビュー メソッドを post クラスから分離しており、post オブジェクトは他の公開タイプとしても使用できることを理解することです。
上記の内容の実装は、編集者が皆さんに紹介したPHPデザインパターンのオブザーバーモードです。