実装へのインターフェイス参照をキャストすることで、著者は何を意味しますか？

私は現在C＃をマスターしようとしていますが、Gary McLean HallによるC＃を介してAdaptive Codeを読んでいます。

彼はパターンとアンチパターンについて書いています。実装とインターフェースの部分で、彼は次のように書いています。

インターフェイスへのプログラミングの概念に慣れていない開発者は、多くの場合、インターフェイスの背後にあるものを手放すのが困難です。

コンパイル時に、インターフェースのクライアントは、使用しているインターフェースの実装を把握していないはずです。このような知識は、クライアントをインターフェイスの特定の実装に結び付ける誤った仮定につながる可能性があります。

クラスが永続ストレージにレコードを保存する必要がある一般的な例を想像してください。そのために、インターフェイスに正しく委任します。これにより、使用される永続的なストレージメカニズムの詳細が隠されます。ただし、実行時にどのインターフェイスの実装が使用されているかについて仮定するのは正しくありません。たとえば、インターフェイス参照を実装にキャストすることは常に悪い考えです。

それは言葉の壁か、私の経験不足かもしれませんが、それが何を意味するのかよくわかりません。ここに私が理解していることがあります：

C＃を練習するための自由時間の楽しいプロジェクトがあります。そこでクラスがあります：

public class SomeClass...

このクラスは多くの場所で使用されています。C＃を学習しているときに、インターフェイスで抽象化する方がよいことを読んだので、次のようにしました。

public interface ISomeClass <- Here I made a "contract" of all the public methods and properties SomeClass needs to have.

public class SomeClass : ISomeClass <- Same as before. All implementation here.

そこで、いくつかのクラス参照をすべて調べて、それらをISomeClassに置き換えました。

私が書いた建設を除いて：

ISomeClass myClass = new SomeClass();

これが間違っていることを正しく理解していますか？はいの場合、なぜそうですか、代わりに何をすべきですか？

クラスをインターフェイスに抽象化することは、前述のインターフェイスの他の実装を書くつもりであるか、将来そうする可能性が高い場合にのみ考慮すべきものです。

おそらくSomeClass、これISomeClassは悪い例です。OracleObjectSerializerクラスとIOracleObjectSerializerインターフェースを持つようなものだからです。

より正確な例は次のようなものになるだろうOracleObjectSerializerとIObjectSerializer。使用する実装を気にするプログラム内の唯一の場所は、インスタンスの作成時です。これは、ファクトリパターンを使用することでさらに分離される場合があります。

あなたのプログラムのどこでも、それがIObjectSerializerどのように動作するかを気にしないで使うべきです。SQLServerObjectSerializerに加えて実装もあると仮定しましょうOracleObjectSerializer。設定する特別なプロパティを設定する必要があり、そのメソッドがOracleObjectSerializerにのみ存在し、SQLServerObjectSerializerには存在しないとします。

対処方法は2つあります。間違った方法とLiskov置換原理アプローチです。

間違った方法

間違った方法、そしてあなたの本で言及されているまさにそのインスタンスは、のインスタンスを取得してIObjectSerializerキャストし、OracleObjectSerializerでsetPropertyのみ利用可能なメソッドを呼び出すことですOracleObjectSerializer。インスタンスがであることがわかっている場合でも、OracleObjectSerializerプログラムに実装が何であるかを知りたいという別のポイントを導入しているため、これは悪いことです。その実装が変更され、おそらく複数の実装がある場合は遅かれ早かれ、最良のケースのシナリオになると、これらすべての場所を見つけて適切な調整を行う必要があります。最悪の場合、IObjectSerializerインスタンスをにキャストするOracleObjectSerializerと、実稼働環境でランタイムエラーが発生します。

リスコフ置換原理アプローチ

LiskovはsetProperty、私のOracleObjectSerializer場合のように、実装クラスのようなメソッドを適切に行う必要は決してないと言った。クラスOracleObjectSerializerをIObjectSerializerに抽象化する場合、そのクラスを使用するために必要なすべてのメソッドを含める必要があります。できない場合は、抽象化に問題があります（たとえば、DogクラスをIPerson実装として機能させようとします）。

正しいアプローチは、setPropertyメソッドを提供することIObjectSerializerです。同様の方法は、SQLServerObjectSerializer理想的にはこのsetProperty方法で機能します。さらに良いことにEnum、各実装がその列挙を独自のデータベース用語に相当するものに変換することにより、プロパティ名を標準化します。

簡単に言えば、anの使用ISomeClassはその半分にすぎません。作成を担当するメソッドの外部にキャストする必要はありません。これを行うことは、ほぼ間違いなく重大な設計ミスです。

受け入れられた答えは正解であり、非常に便利ですが、あなたが尋ねたコード行について簡単に簡単に説明したいと思います。

ISomeClass myClass = new SomeClass();

大まかに言って、これはひどいことではありません。可能な限り避けるべきことはこれを行うことです：

void someMethod(ISomeClass interface){
    SomeClass cast = (SomeClass)interface;
}

あなたのコードが外部的にインターフェースを提供されるが、内部的にそれを特定の実装にキャストする場合、「それはその実装のみになるとわかっているからです」。たとえそれが本当だったとしても、インターフェイスを使用して実装にキャストすることで、抽象化を使用するふりをすることができるように、自発的に実際の型の安全性を放棄しています。他の誰かが後でコードを操作し、インターフェイスパラメータを受け入れるメソッドを参照する場合、そのインターフェイスの実装はすべて渡すのに有効なオプションであると想定します。必要なパラメータについて特定の方法があることを忘れた後の行。インターフェースから特定の実装にキャストする必要があると感じた場合は、インターフェース、実装、またはそれらを参照するコードが誤って設計されており、変更する必要があります。たとえば、渡された引数が特定のクラスである場合にのみメソッドが機能する場合、パラメーターはそのクラスのみを受け入れる必要があります。

さて、コンストラクター呼び出しを振り返って

ISomeClass myClass = new SomeClass();

キャストの問題は実際には当てはまりません。これのどれも外部に公開されていないようであるため、それに関連する特定のリスクはありません。基本的に、このコード行自体は、インターフェースが最初から抽象化するように設計された実装の詳細であるため、外部のオブザーバーは、何をするかに関係なく同じように機能することを確認します。ただし、これはインターフェイスの存在から何も得ません。あなたはmyClassタイプを持っているISomeClassが、それは常に特定の実装を割り当てられているので、それがどのような理由を持っていません、SomeClass。コンストラクター呼び出しだけを変更することでコード内の実装を交換できる、または後でその変数を別の実装に再割り当てできるなど、いくつかのマイナーな潜在的な利点がありますが、変数をインターフェイスに入力する必要がある他の場所がない限りこのパターンの実装により、コードはインターフェースがロートによってのみ使用されているように見え、インターフェースの利点を実際に理解しているわけではありません。

悪い例でコードを表示する方が簡単だと思います：

public interface ISomeClass
{
    void DoThing();
}

public class SomeClass : ISomeClass
{
    public void DoThing()
    {
       // Mine for BitCoin
    }

}

public class AnotherClass : ISomeClass
{
    public void DoThing()
    {
        // Mine for oil
    }
    public Decimal Depth;
 }

 void main()
 {
     ISomeClass task = new SomeClass();

     task.DoThing(); //  This is good

     Console.WriteLine("Depth = {0}", ((AnotherClass)task).Depth); <-- The task object will not have this field
 }

問題は、最初にコードを記述するとき、おそらくそのインターフェイスの実装が1つしかないため、キャストが引き続き機能することです。将来的には、別のクラスを実装してから（私の例が示すように）、使用しているオブジェクトに存在しないデータにアクセスしてみてください。

明確にするために、キャストを定義しましょう。

キャストとは、あるタイプから別のタイプに強制的に変換することです。一般的な例は、浮動小数点数を整数型にキャストすることです。キャスト時に特定の変換を指定できますが、デフォルトでは単にビットを再解釈するだけです。

このMicrosoftドキュメントページからキャストする例を次に示します。

// Create a new derived type.  
Giraffe g = new Giraffe();  

// Implicit conversion to base type is safe.  
Animal a = g;  

// Explicit conversion is required to cast back  
// to derived type. Note: This will compile but will  
// throw an exception at run time if the right-side  
// object is not in fact a Giraffe.  
Giraffe g2 = (Giraffe) a;  

あなたは可能性が実装インタフェース、そのインタフェースの特定の実装に同じこととキャスト何かをする、しかし、あなたはいけません、あなたが期待するものとは異なる実装が使用される場合には、エラーや予期しない動作になりますので。

私の5セント：

これらの例はすべてOKですが、実世界の例ではなく、実世界の意図を示していません。

私はC＃を知らないので、抽象的な例を示します（JavaとC ++の混合）。それでいいことを願っています。

インターフェイスがあるとしますiList：

interface iList<Key,Value>{
   bool add(Key k, Value v);
   bool remove(Element e);
   Value get(Key k);
}

今、多くの実装があると仮定します：

• DynamicArrayList-フラット配列を使用し、最後に高速に挿入および削除します。
• LinkedList-二重リンクリストを使用して、先頭と末尾にすばやく挿入します。
• AVLTreeList-AVL Treeを使用し、高速ですべてを実行しますが、大量のメモリを使用します
• SkipList-SkipListを使用し、高速ですべてを実行します。AVLTreeより低速ですが、使用するメモリは少なくなります。
• HashList-HashTableを使用します

多くの異なる実装を考えることができます。

次のコードがあるとします：

uint begin_size = 1000;
iList list = new DynamicArrayList(begin_size);

それは私たちが使いたいという意図をはっきりと示していますiList。確かにDynamicArrayList特定の操作を実行することはできませんが、必要iListです。

次のコードを検討してください。

iList list = factory.getList();

今、私たちは実装が何であるかさえ知りません。この最後の例は、ディスクからファイルをロードし、そのファイルタイプ（gif、jpeg、png、bmp ...）を必要としない場合の画像処理でよく使用されますが、必要なのは画像操作（フリップ、スケール、最後にpngとして保存）。

ISomeClassインターフェースと、ISomeClassを実装するように宣言されていることを除いてコードから何も知らないオブジェクトmyObjectがあります。

ISomeClassインターフェースを実装するクラスSomeClassがあります。ISomeClassを実装するように宣言されているか、ISomeClassを実装するために自分で実装したためです。

myClassをSomeClassにキャストすることの何が問題になっていますか？2つのことが間違っています。1つは、myClassがSomeClass（SomeClassのインスタンスまたはSomeClassのサブクラス）に変換できるものであることを本当に知らないため、キャストが失敗する可能性があることです。2つ目は、これを行う必要がないことです。iSomeClassとして宣言されたmyClassを使用し、ISomeClassメソッドを使用する必要があります。

SomeClassオブジェクトを取得するポイントは、インターフェイスメソッドが呼び出されたときです。ある時点で、インターフェイスで宣言されているmyClass.myMethod（）を呼び出しますが、これはSomeClassに実装されており、もちろんISomeClassを実装する他の多くのクラスにも実装されています。呼び出しがSomeClass.myMethodコードで終わる場合、selfはSomeClassのインスタンスであることがわかります。その時点で、SomeClassオブジェクトとして使用することは完全に適切であり、実際には正しいです。もちろん、実際にSomeClassではなくOtherClassのインスタンスである場合、SomeClassコードには到達しません。