4

次のコンポーネントがあるとします。

ここに画像の説明を入力

  • Producer は数値を生成し、Consumer にメッセージを送信します
  • Producer と Consumer の両方が Monitor にメッセージを送信します
  • モニターは、たとえばランダムに、生成/消費プロセスをいつ停止するかを決定し、メッセージをストッパーに送信します
  • ストッパーはプロデューサーとコンシューマーの両方をきれいに停止します

これは、Java などの可変言語で簡単に実現できます。here で説明されているように、インターフェースで部分的な可変性を許可することでこれを解決できることも知っています。

ただし、可能であっても循環依存関係を持つことはお勧めできません。したがって、すべての参照がコンストラクターによって注入され、最終的なものであると仮定しましょう。

  • プロデューサーはfinal Consumer、final Monitor
  • 消費者が持っているfinal Monitor
  • モニターはfinal Stopper
  • ストッパーがfinal Producerあり、final Consumer

thisなどの参考文献を見つけましたが、適用されないようです。

このケースと、このような一般的なケースのサイクルを解除するにはどうすればよいでしょうか? つまり、どうすればサイクルを形成しないようにデザインできるかということに一番興味があります。ヒントはありますか？

4

1 に答える 1

2

そうです、すべての依存関係が最終的であり、コンストラクターを介して注入された場合、これは機能しません。

しかし、なぜコンストラクターを介して注入する必要があるのでしょうか? setters結局のところ、 Bean を接続するために使用するのに問題はありません。

実際、Spring では通常、Bean が最初にインスタンス化され、その後に注入されます。したがって、そのアプローチを見ることができます。

それ以外に、別の方法で問題をモデル化することができます (循環依存関係を持たない)。

たとえば、プロデューサーとコンシューマーの間でメッセージを送信するために既にキューを使用しているため、キューのメッセージをモニターにも送信しないのはなぜでしょうか? ストッパーはプロデューサーとコンシューマーにメッセージを送信することもできます。

または、テイラーが提案するように、ESB.

おそらく他にも多くの設計方法があります。いくつかのアイデアについては、(たとえば) Apache Camel Enterprise Integration Patternsを読んでください。

于 2015-06-18T23:08:27.950 に答える