3

同じビジネス エンティティを表すさまざまな種類のオブジェクトがあります。 UIObject、PowershellObject、DevCodeModelObject、WMIObjectすべて同じエンティティに対する異なる表現です。

エンティティがAnimal、AnimalUIObject、AnimalPSObject、AnimalModelObjectなどであるAnimalWMIObjectとします。

AnimalUIObject、AnimalPSObject、の実装AnimalModelObjectはすべて別のアセンブリに含まれています。

今私のシナリオは、Animalそれが元のアセンブリに関係なく、ビジネス エンティティの内容を確認したいということです。そこで、エンティティGenericAnimalを表すクラスを作成しました。Animal

ここでGenericAnimal、次のコンストラクターを追加しました。

GenericAnimal(AnimalUIObject)
GenericAnimal(AnimalPSObject)
GenericAnimal(AnimalModelObject)

基本的にGenericAnimal、基礎となるすべてのアセンブリに依存するようにしたので、検証中にこの抽象化を処理しました。

これを行うもう 1 つの方法はGenericAnimal、空のコンストラクターを使用して、これらの基になるアセンブリTransform()にGenericAnimal.

どちらのアプローチにも、いくつかの長所と短所があります。

第 1 のアプローチ:
長所: すべての構築ロジックは 1 つのクラスの 1 か所にありますGenericAnimal
。 短所:GenericAnimal新しい表現形式があるたびに、クラスを変更する必要があります。

2 番目のアプローチ:
長所: 構築の責任は、基になるアセンブリに委任されます。
短所: 構築ロジックはアセンブリ全体に分散しているため、明日プロパティを追加する必要がある場合は、XすべてGenericAnimalのアセンブリに触れてTransformメソッドを変更する必要があります。

どちらのアプローチが良いですか?
またはどちらがより少ない悪だと思いますか?
上記の2つよりも優れた代替方法はありますか?

私が受け取ったコメントに基づいてさらに詳しく説明します。基になるオブジェクトの構造を変更する余裕はありません。つまり、AnimalUIObject AnimalPSObject などを変更することはできません。GenericAnimal は、検証目的で私が導入したコンストラクトです。

4

3 に答える 3

4

どちらのアプローチもかなり「悪」だと思います。

本当に必要なのは、Animalクラスをコアクラスとして開始し、クラスを使用しAnimalて表現を保持する残りのクラスをラッパークラスにすることだと思います。その後、Animal API に対して検証が実行されます。

于 2012-11-17T04:42:34.297 に答える
0

抽象ファクトリパターンの機会かもしれませんか？

于 2012-11-17T04:44:00.713 に答える
0

同じビジネス エンティティを表すさまざまな種類のオブジェクトがあります。UIObject、PowershellObject、DevCodeModelObject、WMIObject はすべて、同じエンティティに対する異なる表現です。

一般的なデザイン パターン、特に構造パターンを参照してください。

私の理解では、Decorator パターンが役に立ちます。

デコレーター パターンを使用して、同じクラスの他のインスタンスとは無関係に、実行時に特定のオブジェクトの機能を拡張 (装飾) できます。これは、元のクラスをラップする新しいデコレータ クラスを設計することによって実現されます。

したがって、これは最初のアプローチである必要がありますが、短所はありません。

GenericAnimal クラスにはコンストラクターがあります。

GenericAnimal(AnimalObject)

AnimalObjectインターフェイスまたは抽象クラスのいずれかを使用します。

短所: GenericAnimal クラスは、新しい表現形式があるたびに変更する必要があります。

別の表現形式を追加する場合は、implements または extends を作成しますAnimalObject。

于 2012-11-17T05:20:33.093 に答える