Observables / Listenablesをどの程度細かくする必要がありますか?
-
05-07-2019 - |
質問
いくつかの状態が変化したときにオブザーバー/リスナーに通知するプル指向のObservable / Listenableがあります。
状態は複数のデータのナゲットで構成されており、一部のオブザーバー/リスナーは状態全体を気にしません。
通常、すべてのオブザーバー/リスナーに通知し、何も変更が気にならない場合は通知を無視できるようにしますか?
または「ナゲット」ごとに別個のObservableを好むのが一般的ですか?オブザーバー/リスナーが応答する必要がある通知のみを受け取ることが保証されるように、
状況に依存しますか?
Observables / Listenablesの粒度について一般的な考えはありますか?
解決
メンテナンス費用と配送費用をトレードオフしています。きめ細かなイベント定義がある場合、各オブザーバーは必要なものだけを取得するため、関心のないオブザーバーへの配信のオーバーヘッドは支払われませんが、新しい種類のナゲットをすべて追加する必要があるため、コストを節約できます何らかの方法でシステム。
配信コストが比較的高いPub / Subメッセージングシステム(ネットワークを流れるメッセージ)では、通常、トピックの定義に注意を払う必要があります。慎重に設計されたトピック階層は、多くの場合便利です。したがって、次のようなパターンを取得します
sport
football
england
premier
champioship
scotland
spl
france
...
cricket
australia
...
india
sri lanka
したがって、さまざまなレベルでサブスクリプションを許可します。すべてのスポーツを購読するか、(一部の人がそうするように)すぐに
に登録できます sport/football/england/championship/watford
他のヒント
まあ、一般的な経験則として、特殊なインターフェースは害よりも優れているので、私は間違いなく少ないよりも多くを実装します。
これは明らかに状況を呼び出します。必要な場合にのみこの方法に特化し、あなたの状況からはそのように思えます。そうでなければ、小麦の収穫が必要であることを穀物の製造者に知らせるようなものです。適用されません。
これを行う必要がある場合、おそらく、各種類のナゲットのイベントと、任意のナゲットの1つのグローバルイベントを持つObservableクラスを作成します。ちょっと中道のようです。
メンテナンスだけではありません。 ObservablesとObserversの間のインターフェースがより具体的になればなるほど、より結合されます。
Gang Of Fourの本には、この問題に関するセクションがあり、プッシュモデルとプルモデルの両方に反対するアドバイスをしています。プルモデルは非効率的である場合があり、プッシュモデルは十分に再利用できない場合があります。
したがって、状況に大きく依存します。私はプルモデルより少し上に行く傾向があります。