一般的なベストプラクティスと見なされるもの：
スーパータイプによる参照？
public class BirdFeeder{
public Feed(Bird bird){...}
}
またはインターフェース経由
public class BirdFeeder{
public Feed(IBird iBird){...}
}
個人的にはインターフェースが好きですが、理由はよくわかりません。私にとっては、インターフェースが「よりクリーン」だと感じているだけです。なぜ私がどちらかを選ぶのかをもっとよく理解したいと思います。
ありがとう
あなたはインターフェースについて正しいです、それらはあなたの継承階層を設計する際によりあなたにもっと柔軟性を提供します。
基本クラスから始まり、Birdさまざまな種類の鳥に至るまでの階層があるとします。ここで、鳥の階層に機械的な鳥を追加したいが、Robot基本クラスから派生させたいとします。あなたのフィーダーがBird議論をするならば、あなたの機械的な鳥は特別なフィーダーを必要とするでしょう。ただし、フィーダーがを使用する場合、インターフェースが正しく実装されている限り、フィーダーにIBird送信しても問題はありません。RoboBirdIBird
「スーパータイプ」とインターフェースとの比較では、基本的な抽象クラスに焦点を当てたいと思います。（非抽象基本クラスを使用できますが、一般に、抽象メンバーを持たない抽象クラスでさえ、実装/継承を目的としており、型として独立していないことを開発者に伝える傾向があります）
基本/抽象クラスとインターフェースに関しては、全体的な「ベストプラクティス」はありません。彼らは両方とも設計の実践に彼らの場所を持っています。実際、ベストプラクティスは、実装している設計から得られます。
おそらく、設計上の考慮事項に関する最大の違いは、基本/抽象クラスは継承のみが可能であるのに対し、インターフェースはあらゆる種類のクラスに実装できることです。
（編集：pilotcamははるかに優れた例を考え出しました。質問に対する彼のコメントを参照して
ください）たとえば、鳥の例から、オウム、アホウドリ、ペンギンなどのさまざまな鳥を処理したいとしますBird。ただし、アプリケーションは型も処理しDinosaurます。Archeopteryxを実装することができます。Dinosaur継承しますか、それとも継承しBirdますか？代わりBirdにインターフェースである場合は、単純にを使用できますclass Archaeopteryx : Dinsoaur, IBird。この例は少し工夫されていますが（確かにもっと良い例があります）、うまくいけば十分です。
もちろん、基本/抽象クラスもいいです。たとえば、アクセス修飾子を組み合わせることinternalで、APIが実装にアクセスするメソッドを実装することを利用できますが、クラスの外部コンシューマーはアクセスできません。
どちらか一方を他方の上に使用する理由は本当にたくさんあり、どちらも実際にコーディングするのに「優れている」わけではありません。それは本当にあなたのアプリケーションのデザイン、そしておそらくあなたがコーディングしている比喩に依存します。それらのオブジェクトが表しているもの。あなたのオブジェクトは実際には鳥ですか、それとも鳥のように振る舞うだけですか？APIは気になりますか？あなたの仕事のために何を維持するのが良いでしょうか？
ここにもう少し読んでください： インターフェースvs抽象クラス（一般的なOO）（これに「リンクされた」同様の質問すべてに注意してください）
子孫コンポーネントに一連の動作を実装する場合は、抽象クラスを使用します。
有用な共通の祖先を持たない多数のクラスに一連の動作を実装する場合のインターフェース。
どちらかを使用できる状況はたくさんあります。一般に、インターフェイスを使用する設計を作り直し、新しいものを入手し、一連の恐ろしい妥協に縛られることはないことがわかりました。インターフェイスを定義してから、インターフェイスがない場合よりも、抽象クラスにその子孫用に実装させたいと思います。最初は些細な量の余分な作業であり、後で大きなメリットが得られます。