インターフェイスはタイプAを公開しますが、実装にはタイプB（Aのサブクラス）が必要です

Question

私はしばらくレスリングしてきたシステムを持っています。基本的には、後で拡張が予想されるだけでなく必要であるという事実に対処するために、多くの抽象化を使用しています。これが必要な場所は、データアクセスです。このシステムでは、一般的に、（観察された値または値のセットの意味で）いくつかの観察をカプセル化し、それらを使用するオブジェクトの管理が扱われます。この目的のために、私は次のようなものを持っています。

public interface Observation 
{ 
    /** UniqueKey is used to access/identify an observation */ 
    UniqueKey Key 
    { 
     get; 
    } 
} 

public interface ObservationDataSource 
{ 
    /** 
     * Retrieves an Observation from the actual data source. 
     * performs any necessary operations to encapsulate values in object 
     */ 
    Observation GetObservationByUniqueKey(UniqueKey key); 
} 

問題は、これらのインターフェイスの特定の実装で発生します。最終的に、ObservationおよびObservationDataSourceクラスは、特定のランタイムクラスで実装されます。しかし、UniqueKeyは、データソース内の観測（一意のid、多分時刻など）の一意の識別値セットを処理するために拡張することもできます。したがって、GetObservationByUniqueKeyの実装では、UniqueKey引数が公開されますが、特定のサブクラスが必要です。

これは、実装が引数の要件について嘘をついているので、これは設計上の選択肢が貧弱だと思われますが、これを行う別の方法はわかりません。私は他の人がこれらのインターフェースを使用することを期待しているので、私はこの規約を覚えているとは言えません。

それを修正したり、よりエレガントに扱うためのアイデアはありますか？

Answer 1

私は単にあなたのこの1文で修正することによって、問題としてこれを見ていない：

ので GetObservationByUniqueKeyのいずれかの実装はUNIQUEKEY引数を を公開しますが、しかし 特定のサブクラスを期待する場合とUniqueKeyが ObservationDataSourceによって生成された場合は、 とします。 UNIQUEKEYが期待されるタイプではない場合、それは2つの方法のいずれかを処理することができるだけの些細な拒否のケースだ

：

（1）あなたのObservationDataSourceインターフェイスにUniqueKeyTypeプロパティを露光することにより、呼び出し側GetObservationByUniqueKeyのUniqueKeyのインスタンスタイプを先験的にチェックできます。

（2）各GetObservationByUniqueKeyの実装者は、UniqueKeyが生成されなかった場合を処理する責任を負います。

しかし、あなたのデータ問題を解決するために定義されたルックアップ関数を既に持っている場合、最初にUniqueKeyを多態性にすることを許可しているのはなぜですか？

Answer 2

これはあなたが望むものであるならば、私はわからないんだけど、それはあなたがジェネリックでそれをやってみてください可能性が私には思える：

public interface Observation<T> where T : UniqueKey 
{ 
    T Key { get; } 
} 

public interface ObservationDataSource<T> where T : UniqueKey 
{ 
    Observation<T> GetObservationByUniqueKey(T key); 
} 

今インターフェースは強くあなたのUNIQUEKEYの特定のサブクラスに入力されますクラスが必要です。

Answer 3

あなたはHowerverが、これは間違っている、

、そうGetObservationByUniqueKeyのいずれかの実装はUNIQUEKEY引数を公開します

を言います。それは議論を公開しません - それは1つを受け取るでしょう。あなたが言うように、呼び出し側は任意の一意のキーを渡すかもしれません。何も問題はありません。

特定のデータソースでは、特定のユニークキーのみが特定のwrtだけでなく、関連する観察結果を持ちます。タイプだけでなく、特定のwrt。実際の値に変更します。値に関連付けられた観測値がない場合は、nullを返します（私は仮定します）。 uniqueidの型が間違っている場合も同じことを行います。誰かがIDが期待される時刻を過ぎても、そのデータソース内のそのキーに関連付けられている観測値はありません。

OTOH、呼び出し側が固有のIDを選択して自由であり、データソースは、発信者によって満たされる空の観察を返すことになっている場合は、次の2つの選択肢があります。

1. 使用しないでくださいを最初の場所にインターフェイスがあります。どうやら、一方の実装をもう一方の実装に置き換えることはできず、呼び出し元はそれらの実装がどの実装を使用しているのかを認識していなければなりません。
2. また、すべての実装がすべての種類の一意のキーをサポートしていることを確認してください。