インターフェースとポリモーフィズムの関係がわかりません。
私にとってのポリモーフィズムは、抽象メソッドまたは仮想メソッド+オーバーライドを使用して、いくつかの異なる具象クラスに対して異なる方法でメソッドを実行することです。したがって、これは私のビジョンの継承にのみリンクされていますが、インターフェイスを使用してメソッドをオーバーライドするにはどうすればよいですか？インターフェイスをどのように使用して、同じメソッドをさまざまな方法で実行し、オブジェクトに具体的なタイプに応じて何を実行するかを決定させますか？
ありがとう
AndreasHartlが継承対に関する彼の記事で述べたように。インターフェース：
多くの高級言語は継承とインターフェースをサポートしており、概念に不慣れな人にとっては、どちらを選択するかが明確でない場合があります。言語は継承とインターフェースの正確な処理が異なりますが、基本は通常同じであるため、このヒントはほとんどの言語で有効です。
継承とは、あるクラス（派生クラス）を別のクラス（基本クラス）から派生させることを意味します。派生クラスは、基本クラスの拡張です。これには、基本クラスのすべての機能（メソッドとデータメンバー）が含まれ、新しい機能で拡張でき、基本クラスの仮想メソッドを再実装できます。C ++などの一部の言語は、多重継承をサポートします。派生クラスは複数の基本クラスを持つことができますが、通常、継承は単一の基本クラスに制限されます。
インターフェイスは通常、メソッドのみを定義でき、データメンバーは定義できません（ただし、たとえばC＃では、インターフェイス内のプロパティの形式でデータメンバーを使用できます）。また、クラスは常に複数のインターフェイスを実装できます。インターフェイスには実装のないメソッド定義のみが含まれ、インターフェイスを実装するクラスが実装を提供します。
したがって、継承を使用して、メソッド実装を使用して基本クラスを記述し、そこからクラスを派生させると、このクラスは基本クラスからすべてを継承し、すぐにその機能を使用できるようになります。一方、インターフェースは単なるメソッド署名のコントラクトであり、インターフェースを実装したいクラスは、インターフェースのすべてのメソッドの実装を提供することを余儀なくされます。
では、いつどちらを使用しますか？場合によっては、言語によって使用内容がすでに決定されています。クラスに複数の「親」が必要な場合、多重継承をサポートしていない言語で継承を使用することはできません。また、ライブラリオブジェクトを再利用する場合は、そのライブラリオブジェクトがクラスであるかインターフェイスであるかに応じて、フィッティングの概念を使用する必要があります。
しかし、自由に選択できる場合はどちらを使用しますか？基本的に、基本クラスは関連する型の一般的な動作を記述および実装しますが、インターフェースは関連しない型が実装できる機能を記述します。継承は「関係」を記述し、インターフェースは「関係」のように動作します。たとえば、フライトシミュレータを作成しているとします。たとえばリストに保存する基本エンティティは、「飛行機」になります。具体的なタイプは「コンコルド」と「ファントム」になります。では、3つのタイプをどのようにモデル化する必要がありますか？ConcordeとPhantomは関連しており、どちらも飛行機であり、「Weight」や「MaxSpeed」などのデータと「Accelerate」などの機能を共有しているため、継承を使用してモデル化できます。'飛行機' は共通のデータとメソッドを持つ基本クラスになり、「Concorde」と「Phantom」は「Airplane」から派生します。どちらも特殊な飛行機と言えるので、継承とは特殊化を意味するとよく言われます。ここで、プログラムにクラス「Pilot」も追加し、ユーザーがゲームを保存して後でロードできるようにしたいとします。したがって、彼がゲームを保存するときは、すべての航空機の状態とすべてのパイロットの状態を保存する必要があります。そして、すべての保存可能なオブジェクトのリストだけを取得する1つの関数でこれを実行したいと思います。では、これをどのようにモデル化するのでしょうか。これに答えるには、保存したいさまざまなタイプを確認する必要があります。パイロットと飛行機。それらがまったく関連していないことは明らかです。それらは共通のデータも共通の機能も共有しません。基本クラス「Saveable」を記述し、そこからPilotとAirplaneの両方を派生させることはほとんど意味がないことがわかります。これは、SaveableのコードはAirplaneまたはPilotで再利用できないため、両方に共通のプロパティがないためです。この場合、インターフェースが最良の解決策です。Save（）メソッドを使用してインターフェース「ISaveable」を記述できます。パイロットは名前を保存してISaveable.Save（）を実装でき、飛行機は現在の速度と座標を保存できます。
ご覧のとおり、クラス間の関係を明確にイメージすると、多くの場合、選択が明確になります。関連する型に継承を使用します。ここで、各派生クラスは'基本クラスです。いくつかの共通の機能を持つ無関係なタイプのインターフェースを使用します。
継承とインターフェースに関して考慮すべきいくつかのポイントがあります。
インターフェイスは固定されています。インターフェイスを変更するときは、そのインターフェイスを実装するすべてのクラスを変更する必要があります。ただし、基本クラスを変更すると、すべての派生クラスに新しい機能が追加されます。これは両方とも優れています（基本クラスのメソッドの実装でバグ修正を行うと、そのメソッドを使用する派生クラスは変更せずにバグ修正を取得できます）それ）または悪い（基本クラスの変更によって新しいバグが発生した場合、メソッドを使用するすべての派生クラスにもバグが発生します）。
ほとんどの言語では1つのクラスからしか派生できないため、インターフェイスは通常より柔軟ですが、多くのインターフェイスを実装します
インターフェイスは内部クラスの保護に役立ちます。クラスAにクラスBの内部オブジェクトbがあると仮定します。Aのメソッドがbへのポインタまたは参照を返すと、このメソッドを呼び出したコードはオブジェクトb全体にアクセスできるようになります。 Aがbの特定のメンバーのみを公開したい場合は危険です。この問題は、公開しても安全なメンバーだけを使用してインターフェイスIを作成すると解決できます。Bがこのインターフェイスを実装し、AのメソッドがIポインタまたは参照を介してbを返す場合、外部コードはインターフェイスを介して許可されたもののみを実行できます。
概念としてのポリモーフィズムは継承を必要としませんが、多くの言語では継承がそれを達成する唯一の方法です。smalltalkなどの一部の言語では、同じメンバーとプロパティのセットを実装する任意のタイプを多態的に使用できます。アヒルのように見え、アヒルのように鳴き、アヒルのように歩く場合は、アヒルのように扱うことができます。
ポリモーフィズムとは、元のオブジェクトにアクセスして使用するのと同じ方法を提供することにより、あるオブジェクトを別のオブジェクトとして扱う機能のことです。これは、リスコフの置換原則によって最もよく示されています。これは、別のオブジェクトがオブジェクトに対して興味深いことを行うために使用できる「署名」を定義するため、「インターフェース」または「コントラクト」と呼ばれることもあります。
C＃では、インターフェイスまたは他の（シールされていない）クラスから継承できます。違いは、インターフェースが実際のストレージやメソッド（「署名」のみ）を提供せず、単なる定義であるということです。インターフェイスをインスタンス化することはできません。インスタンス化できるのは、インターフェイスを実装するオブジェクトのみです。
クラスは、青写真に基づいて家を建てるのと同じ方法でインターフェース（IDisposableなど）を実装します。同じ設計図で2つの家を建てる場合、各家はまったく同じ「インターフェース」を持ち、異なる色のペンキやカーペットを使用している可能性がありますが、まったく同じように機能しますが、2つの明確に異なる家であり、多くの家があります。さまざまな機能の違い。
C＃に関しては、インターフェイスが、それを実装するオブジェクトが持つ必要のあるプロパティまたはメンバーを示していることを知っておいてください。同様に、C＃では、大きな違いは、複数のインターフェイスを継承できますが、単一のクラスしか継承できないことです。（すなわちpublic class Test : BaseClass, IDisposable, ITest, IFooBar）
このことを考慮...
public int SomeMethod(SomeBaseClass object)
{
// Pass in a descendant classe that implements / overrides some method in SomebaseClass
}
public int SomeMethod(ISomeInterface intf)
{
// pass in concrete classes that implement some ISomeInterface function
}
これは、専門家クラスによって特別に実装された、一般的な契約であるポリモーフィックな動作の基本的な本質です。