6

コントローラーは、ユーザーからいくつかの果物のリストを受け取ります。コントローラーは、これらの果物のそれぞれからジュースを作る必要があります。1台のジューサーでオレンジとグレープフルーツからジュースを作ることができます。別のジューサーは、リンゴ、バナナ、パパイヤからジュースを作ることを知っています。等々。すべてのジューサーは、一度に複数のフルーツを受け入れることができます。処理できるフルーツのみを処理し、他のフルーツはそのまま無視します。この問題に対する適切な設計を親切に提案してください。次のオプションを検討しています。

  1. コントローラーの呼び出しMasterJuicer.juice(List<Fruit> fruits)MasterJuicer順番に と を呼び出しCitrusJuicer.juice(fruits)ますPulpyJuicer.juice(fruits)
  2. 責任の連鎖は正しくないようです。Juicers が呼び出される順序は関係ありません。
  3. 工場?コントローラーを呼び出しJuicerFactory.getJuicers(List<Fruit> fruits)て を取得しList<Juicer>ます。次に、コントローラは各 Juicer をループして を呼び出しますJuicer.juice(fruits)。Factory がインスタンスのリストを返すのは一般的ですか?
  4. Fruit vs. Juicer のレジストリをMap? コントローラーはFruitsRegistry.getJuicer(Fruit fruit)各フルーツを呼び出し、ループ内で各ジューサーを呼び出します。
4

5 に答える 5

2

私の意見では、あなたが探しているパターンは責任の連鎖です

http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern

よろしく

于 2013-05-28T13:04:21.800 に答える
2

工場は正しいジューサーを提供できますが、ジューサー処理ロジックはコントローラーにプッシュされます。

複合パターンと訪問者パターンの組み合わせが役立つ場合があります。

  1. 複合パターンを使用すると、他のジューサーを認識し、ジューサーに委任することで「ジューシング プロセス」を開始できるMasterJuicerを構築できます。これにより、問題の「構造的」側面が処理されます。
  2. ビジター パターンにより、各ジューサーは、呼び出し元 (複合 MasterJuicer) がどのように連携するかを気にすることなく、ジューサーと対話するための統一された方法を持つことができます。これは「行動」の側面を処理します。

各訪問者間で処理する材料のリストを渡すことができるため、訪問者は関心のある果物と対話できます。

ジューサーを手動で MasterJuicer に登録したくない場合は、ある種のサービス ディスカバリーを賢く使いたいと思うかもしれません。Java での一般的な手法は、注釈とクラスパス スキャンを使用して実行時にクラスを検索し、起動時にそれらを自動的に登録することです。これを行うライブラリがいくつかあります。Spring Framework をすでに使用している場合は、組み込みのスキャン ツールを使用できます。

于 2013-05-28T12:12:55.737 に答える
1

これは間違いなく責任の連鎖です。Juicers果物がなくなるまで、どういうわけか繰り返してジュースを作ります。考慮すべきいくつかのことは、得られたジュースを混合する必要性 (おそらく の複合パターンJuice) と、優先順位を調整する方法 (2 つのジューサーがグレープフルーツをジュースにする場合、どちらがそれを行うべきか?) です。このすべてのロジックをJuicerインターフェイスの背後にカプセル化します。

于 2013-05-28T13:21:03.697 に答える
0

デコレータパターンをお勧めします

主なアイデアは、ベースのジューサーがあり、それに他の機能を追加することです。

それが役に立てば幸い!

于 2013-05-28T10:01:41.250 に答える