0

定義されたインターフェイス GraphStructure に準拠する機能的な AdjacencyListGraph クラスがあります。これに対する制限 (たとえば、非循環、非 null、一意の頂点データなど) を階層化するために、それぞれ GraphStructure インターフェイスを使用する 2 つの可能なルートを確認できます。

  1. 考えられるさまざまな制限を指定する一連のビットフラグを持つ単一のクラス (「ControlledGraph」) を作成します。このクラスのすべての制限を処理します。新しい制限要件が明らかになった場合は、クラスを更新してください。

  2. デコレーター パターン (基本的には DI) を使用して、クライアント クラスが使用したい個々の制限ごとに個別のクラス実装を作成します。ここでの利点は、単一責任の原則を順守していることです。

私は後者の方に傾きますが、Jove! によると、私はデコレータ パターンが嫌いです。それはクラッターの縮図、IMOです。正直なところ、最悪の場合に適用される可能性のあるデコレータの数によって異なります。これまでの私の場合、カウントは 7 です (この段階で認識した個別の制限の数)。デコレーターのもう 1 つの問題は、すべての... 1 つの... デコレーター クラスでインターフェイス メソッドのラッピングを行う必要があることです。ああ。

どちらかだとしたら、どちらに行きますか？または、よりエレガントなソリューションを提案できる場合は、それを歓迎します。

編集: 提案された ControlledGraph クラスを戦略パターンで使用すると、ここで役立つ可能性があると思います...さまざまなグラフ標準インターフェイスメソッドで個別のビットを個別のコントロールに適用する、ある種のテンプレートメソッド/ファンクターのセットアップ。それとも私はプロットを失っていますか？

4

1 に答える 1

0

ああ、今見えます。ControlledGraphクラスの戦略パターンは確かに進むべき道です。

各制限は個別の戦略クラスです。これらはそれぞれGraphStructureインターフェース全体を実装しますが、ほとんどのメソッドは空のままになります（たとえば、非周期的な制限は、サイクルの挿入を防ぐためにaddEdge（）を使用することにのみ関心があり、他のメソッドは空のままになります）。

ControlledGraphが呼び出されるインターフェイスメソッドの1つを持つたびに、ControlledGraphは、含まれる各戦略/制限の一致するメソッドを呼び出します。明らかに、それは各タイプの戦略の1つだけを保持するかもしれません。

于 2010-03-24T23:02:09.847 に答える