-1

私は、一般的な概念を説明するクラスと、その概念の分散を説明するサブクラスを持っている傾向があります。たとえば、Polygon<|-{、、RectangleなどTriangle}。

ただし、これらの階層のさまざまな表現があることに気付くことがよくあります。たとえば、グラフィック表現（QPolygonなど）や物理表現（mass、centerOfMass）などを別の表現とは別にしたいと思います。

私の場合、純粋なデータオブジェクトの階層（Command<|-{ WaitCommand、UnknownCommandなど}）があり、各データクラス（WaitCommandPanel、UnknownCommandPanel）に一致するGUI表現があります。

私の問題は、データ表現を作成したら、データからGUIに飛躍する必要があることです。

データオブジェクトのリストを前提として、対応するGUI要素を作成できるようにしたいのですが、2つの表現を分離したままにしておきます。

[お粗末な]解決策の1つは、それぞれがGUI表現を返すCommand機能（つまり）を持つことです。Command::getPanel()私のデータクラスには表現コードが含まれているので、これは好きではありません。

もう1つの解決策（当面は採用しました）は、ルックアップを実行することです。つまり、GUIを開始するときに、Commandsのリスト（一般化）が与えられると、関数はその特殊なタイプに基づいて作成するオブジェクトを決定します。私もこれが好きではありません。

助言がありますか？

4

2 に答える 2

0

IMHO、データクラスもレンダリングクラスも、特定のデータオブジェクトに使用するレンダラーを決定する責任はありません。私はあなたの2番目のオプションを好みます。私は通常、データ型をレンダラー クラスにマップするマップを使用します。また、このようなマッピングはコンテキスト固有であることにも注意してください (Web レンダリングは、destop アプリまたはフィットネス コンテキストとは異なるレンダラーを使用します)。

このようなマッピングは、たとえば属性 (.Net の場合) または命名規則 (Lua の場合) を使用して、自動的に構築できます。または、外部の XML 構成ファイルを使用します。

要約: 誰かがその決定を下す必要があり、SRP によれば、レンダラーもデータ オブジェクトもその責任を負わないものとします。このようなロジックはアプリケーション コンテキスト固有であり、そのため、これらのアクター (つまり、レンダラーとデータ) の両方の「上」にある必要があります。

于 2010-07-08T20:52:28.367 に答える
0

Inversion of Control (IoC) コンテナを使用してクラスを構築することを検討することをお勧めします。

各クラスには、関連するクラスのインターフェースが含まれます。IoC コンテナーは、構成方法に従って、そのクラスの実装をオブジェクトに挿入します。

于 2010-07-08T20:57:15.373 に答える