ILogin と呼ばれる汎用インターフェイスから始めました。インターフェイスでは、UserID と Password の 2 つのプロパティを実装する必要があります。このインターフェースを実装するログインタイプのクラスが多数あります。私のプロジェクトが大きくなるにつれて、多くのクラスが UserID と Password コードを繰り返していることに気付きました。ここで、ベース Login クラスが必要であると判断しました。
ILogin インターフェイスを実装する抽象基本ログイン クラスを作成し、すべての具象クラスを抽象クラスから継承し、必要に応じてオーバーライドすることは適切ですか? 当初はこれで問題ないと思っていました。それから、 ILogin はおそらく私の抽象クラスによってのみ実装される可能性が高いため、不要であると考え始めました。
抽象クラスとインターフェースの両方を維持する利点はありますか?
ありがとう！
間違いなく。具体的な例を考えてみましょう。
抽象クラスがあるとしましょうAnimal。Catたとえば、いくつかのサブクラス、、、、を作成DogしMosquitoますEagle。抽象クラスのメソッドをEat()実装Breathe()できます。Sleep()Animal
ここまでは順調ですね。ここで、とクラスのFly()メソッドが必要だとします。これらの2つの生物はあまり関連性がないため（1つは鳥、もう1つは昆虫）、抽象クラスとして持つことができる2つの共通の祖先を思い付くのは簡単ではありません。これは、インターフェースによって実装するのが最適です。MosquitoEagleIFly
IFlyインターフェイスには、実装するメソッドを含めることができますFly()。MosquitoとEagleクラスは両方とも抽象クラスのサブクラスであり、Animalインターフェースを実装し、2つのクラス間にある種の奇妙な祖先関係を持たずに、、、を実行できますIFly。Eat()Breathe()Sleep()Fly()
私は通常、理にかなっている場合は抽象クラスに対してコーディングし、すべてのクラス (抽象かどうかに関係なく) にインターフェイスを実装 (および外部コントラクト アセンブリ/ライブラリで作成) するので、必要に応じて Windows Communication Foundation または制御の反転をより簡単に実装できます(ほとんどの場合、モック用です）。これは私にとって第二の性質になりました。
抽象クラスがインターフェースを実装する唯一のクラスである場合は、いつでも抽象クラスのインスタンスをチェックできます。インターフェースは必要ありません。ただし、抽象クラスを拡張しないがインターフェイスを使用できる、まだ作成されていない新しいクラスと将来互換性を持たせたい場合は、今すぐインターフェイスを使用し続けてください。
絶対。インターフェースは常に正しい方法です。そのようにすれば、何でも (すでに親を持つものを含めて) 実装できます。
抽象クラスはそれを実現する傾向があるため、その機能の一部を再実装する必要はありません。Swingはそれを少し使用します.5つのメソッドの1つだけをオーバーライドするためのインターフェースとデフォルトの実装があります.またはリスナーの追加を処理する場合があります.したくない。
私はcfedukeに同意します。私は常にインターフェースから始め、過去には、インターフェースを実装し、抽象クラスから継承するクラス間でコードの再利用を促進するための基本的な機能を提供する抽象クラスを使用していました。モックとIOCは、一般的にインターフェイスに依存します。この理由だけで、デザインでインターフェイスを使用します。
抽象クラスに機能がある場合は、それを維持するのが賢明です。ただし、抽象メソッドのみが含まれ、フィールドが含まれていない場合。両方を保持しても意味がありません。
編集:多くの抽象クラスを使用してレガシー コードに取り組んでいます。時間があれば、インターフェイスを追加します (そして、おそらく空の要約を削除します)。インターフェイスを使用すると、可能性が大幅に向上するためです。そして、インターフェイスを正確に定義することで、その名前を尊重します。
インターフェイスは、オブジェクトが受け入れられるために満たされなければならないコントラクトを定義します。抽象クラスは、満たす必要がある契約を定義し、特定の実装の詳細を定義します。
このように考えてください。抽象クラスがスケッチする方法とは異なる方法でその契約を履行したいと考える人がいると思われる場合 (たとえば、別のバッキング データ型の実装を使用)、インターフェイスと抽象クラスの両方を用意する必要があります。それを実装します。
抽象クラスとインターフェースの両方を持つことに伴うオーバーヘッドはほとんどありません。そのアプローチのリスクには、主に、後のコーダーがインターフェースに出くわし、インターフェースを実装する抽象クラスがあることに気付かず、必要のない実装全体をゼロから作成することが含まれます。これは、インターフェースのドキュメントで、抽象クラスにインターフェースの「デフォルト」実装があることを指定することで回避できると思います。いくつかのコーディング標準はその慣行に眉をひそめているかもしれませんが、私はそれに実際の問題は見当たりません。
インターフェイスを使用することを常にお勧めします。抽象クラスには、デフォルトの機能を追加できるという利点がありますが、ユーザーが単一の継承を使用することを要求することは非常に積極的です。
Microsoftのクラスライブラリは、基になるクラスを変更できるため、多くの場合、インターフェイスよりも抽象クラスを優先します。抽象クラスにメソッドを追加すると、それを継承する人が壊れることはめったにありません。インターフェイスにメソッドを追加すると、常にその実装者が壊れます。ただし、これはインターフェイスを使用する最も良い理由の1つです。Microsoftがすでに1つの継承を使い果たしている可能性があります。
ただし、特定のケースでは、使用しているデザインパターンを再検討することをお勧めします。「ログオン型」のクラスがたくさんあるのは珍しいようです。
インターフェイスを維持することの利点は、将来のクラスが複数のインターフェイスを実装できることですが、クラスは1つの抽象クラスからしか継承できないと思います。
別のメソッドセットを使用して新しいインターフェイスを作成することにより、サブクラスの機能を拡張できます。
インターフェイスと抽象クラスが同じシグニチャを持っている場合を具体的に尋ねていると仮定します...
...（インターフェイスのメンバーが抽象クラスのメンバーと何らかの形で異なる場合は、もちろん答えは「はい」です。両方が必要になる場合があります）
...しかし、メンバーが同一であると仮定すると、両方が必要だと私が考えることができる唯一の理由は、複数の実装の継承を許可しないシステムでコーディングしている場合、システム内に多形的に類似している必要がある2つのクラスがあることです、ただし、異なる基本クラスから継承する必要があります。