SplObserver通知の問題

Question

私は、ログの問題を解決する方法としてSplObserverパターンを探しています（つまり、関心のあるクラスに直接実装せずにアクティビティログを処理するため、どのようにしてisn彼らの責任範囲に直接関係している）。

問題が実装されると、SplObserverは、通知クラスが「通知をトリガーしています」以外の詳細を監視クラスに送信するための標準化されたメカニズムを提供していないようです。

他の人がこの問題をどのように克服しているのか不思議でしたが、SplObserverとSplSubjectのインターフェイスを拡張したり、代わりに独自のインターフェイスを使用したりしていましたか？

オブザーバーが指定できるオブザーバーパターンを実装することが可能だった場合は、（オブザーバーで実装可能な他の機能と同様に）特定のイベントではなく、サブジェクトが生成するすべてのイベントではありません。たとえば、すべてのアクティビティをログファイルに記録するログオブザーバが必要になるだけでなく、エラーが発生したときにのみエラーが発生したときに管理者に電子メールを送信するエラーレポートオブザーバも必要です。特定の種類の通知が送信されるようにこのパターンを変更することが可能であると仮定して、エラーによってトリガされない通知を無視するようにエラーロガーを作成できますが、これは理想的ではないと考えられます。私はオブザーバーに特定のサブジェクトイベントのみを購読させることは良いと思うが、そのアプローチはSplObserverで実装できますか？

Answer 1

通知を送信するときにsplSubjectが送信します。対象にコールバックメソッドを実装して、オブザーバーが正確に何が変更されたかを把握することができます。

function update(SplSubject $subject) { 
    $changed = $subject->getChanges(); 
    .... 
} 

このテーマでは、getChanges（）の存在を強制するために、おそらく新しいインターフェースを作成する必要があります。

異なる種類の通知では、メッセージキューシステムを見ることができます。これにより、別のシステム（件名）が対応するキューにメッセージを送信すると通知を受け取る、さまざまなメッセージボックス（ 'logging.error'、 'logging.warning'、または 'logging'）を購読することができます。 splObserver/splSubjectとして実装するのはそれほど難しくありません。