0

アプリケーションを設計するためのパターンを探しています。固定数のエンティティ クラスがあります。例: PostEntity、ArticleEntity、DocumentEntity。それらはすべて、抽象クラス「エンティティ」のサブクラスです。ここまではシンプルに見えます。今日、新しい要件がありました。エンティティ クラスの実装はシステムによって異なります。つまり、SystemA、SystemB、SystemC という複数のシステムが必要です。各システムは、独自の PostEntity、ArticleEntity、DocumentEntity クラスを実装する必要があります。

どのように合理的な方法でクラスを作成しますか?

簡単な方法は、システムごとにフォルダーを作成し、クラスを SystemAPostEntity、SystemAArticleEntity、SystemADocumentEntity のように配置することです。等々。次に、おそらく Factory メソッドを使用してオブジェクトを作成します。たとえば、「SystemA」の「PostEntity」のオブジェクトを取得するには、ファクトリはエンティティ タイプのスイッチ/ケースを使用し、このスイッチ/ケース内でシステムの別のスイッチ/ケースを使用する必要があります。この方法は私には正しくないようです。別のアイデアがあることを願っています。

ありがとう

4

1 に答える 1

0

複数のエンティティを処理する必要があり、各エンティティがシステムごとに異なる動作のセットを持っている場合、指数関数的なクラスの爆発が発生する可能性があります。そして、私はその部分が間違っているとは思いません、それは物事のあり方を表しているだけです。ここで探すべき唯一の警告は、コードの複製を開始した場合です。

サブクラス化のアプローチを取ることは、私には最初は問題ないようです（つまり、Entity>> PostEntity>>を持っていますSystemAPostEntity）。次に、 Abstract Factoryを実装して、システムごとに具体的なファクトリを作成できます。最終的には次のようになります。

abstract class SystemFactory
{
public createPost(params);
...
}

class SystemAFactory extends SystemFactory
{
public createPost(params) 
  {
      return new SystemAPostEntity(params);
  }
}

このようにして、各システムには、そのオブジェクトを作成するファクトリがあります。

考慮すべきことの1つは、特定のシステムのすべてのエンティティがいくつかの共通の動作を共有しているかどうかです（たとえば、タイムスタンプとそれに関連する動作を保持する必要があります）。その場合、すべてSystemX*のクラスでコードを複製するのではなく、その一般的な動作を1つのクラスにグループ化し、委任を使用するようにしてください。一部の言語はTraitをサポートしており、委任のコーディングを回避するのに役立つ場合があります。

HTH

于 2013-03-12T12:00:16.500 に答える