実行時にJavaで既存のデータ構造を強化するためのデザインパターン

Question

小さな例から始めます：

2つのエンティティを持つアプリケーションを想像してみてください。

エンティティA -1 --- N-> EntityB -1 --- N-> EntityC

のは、我々はEnityCインスタンスのリストを返すサービスメソッドがあるとしましょう。 UIでは、EntityCを表示するだけでなく、UIに関連する追加情報（おそらくCSSクラスなど）をエンティティに追加する必要があります。これを解決する一般的な方法は、追加情報をも運ぶことができるラッパーarround EntityCを作成することです。

public class EntityCWrapper implements EntityC, AdditionalInfo { ...} 

または多分、単純なデータ構造として転送オブジェクトを使用します。

public EntityTO { 
    public EntityC entity; 
    public AdditionalInfo info; 
} 

しかし、どのようなサービスはEnitityAインスタンスのリストを返し、我々は（インスタンスグラフ内のすべてのエンティティにAdditionalInfoを添付する必要がある場合EntityBとEntityCの参照されたエンティティインスタンスを含む）？

このような状況に適したデザインパターンを誰かが持っていると思いますか？

Answer 1

Role Object Patternをご覧ください。

オブジェクトをさまざまなもの（「ロール」と呼ばれる）でどのように拡張できるかを説明しています。 パターンはBussiness Logicを追加する方法に関するものです（これが役割と呼ばれる理由です）が、アイデアが役立つかもしれません。

Answer 2

AdditionalInfo仮定は、インスタンス固有の（すなわちEntityCの各インスタンスは、AdditionalInfoインスタンスに固有の121の関係を有する）最良のオプションは、メンバー/ ...、任意で充填されるように、その内部AdditionalInfoを含むようにEntityC定義を強化することであろうあなたによって

EntityCを制御できない場合は、2つのオプションの間にTransferObjectが優れているようです。そのように新しいオブジェクト（EntityC）を作成する必要はありません。だからあなたのデータモデルは、基本的に1からnまでの例として、次のオブジェクトを使用している

Answer 3

（それがされるように工夫）

class Thing 
{ 
    Collection<DooDad> dooDads; 
}  

class DooDad 
{ 
    Collection<DooDadDetail> details; 
} 

class DooDadDetail 
{ 
    ... 
} 

だから私は、n層アーキテクチャの観点から、私のモデルとしてこれを扱っていましたしたがって、これは正確に自分のデータベースにマップする必要があります。何が起きるかは、あなたのモデルが何かをしたいと思っていることです。したがって、ビジネスロジックや外部サービスとやりとりすることができるオブジェクトで構成されるオブジェクトを作成する必要があります。この場合、転送オブジェクトを作成することは、モデルが有効であり、あなたと外部のサービスの間のインターフェイスがモデルに依存しないことを保証するので正しいでしょう。ファサードパターンとデータ転送オブジェクトの一種です。