インターフェイスを使用する利点は、ソフトウェア コンポーネントの具体的な実装に対するパーツの依存関係が減少することです。投稿した1行では、特典が表示されません。そのインターフェースの消費者は利益を得ることができます。
編集:抽象化に関するこの記事を読むことをお勧めします。
たとえば、 so のようなインターフェースを受け入れるメソッドがあるとしますRent(IMovie)
。別の人は、メソッドを呼び出すときに渡す型Rent()
の詳細を知らなくても、メソッドの実装を作成できます。その後、請求方法が異なる可能性のある複数の異なる実装IMovie
を作成できますが、方法はそれを処理する必要はありません。IMovie
Rent()
void Rent(IMovie movie)
{
var price = movie.Price();
movie.MarkReserved();
}
public interface IMovie { }
public class Oldie : IMovie
{
private decimal _oldieRate = 0.8;
public decimal Price()
{
return MainData.RentPrice * _oldieRate;
}
public decimal MarkReserved()
{
_oldiesDb.MarkReserved(this, true);
}
}
public class Blockbuster : IMovie
{
private decimal _blockbusterRate = 1.2;
public decimal Price()
{
return MainData.RentPrice * _blockbusterRate ;
}
public decimal MarkReserved()
{
_regularDb.MarkReserved(this, true);
}
}
これはインターフェイスが有用である理由の例ですが、コード設計のあまり良い例ではありません。
経験則として、メソッドが機能するために必要な最小限の入力しか必要とせず、その出力が、他のユーザーが呼び出したときに使用できる情報をできるだけ多く提供するように、メソッドを作成する必要があります。たとえば、次の署名を見てください。
public List<Entity> Filter(IEnumerable<Entity> baseCollection){ ... }
このメソッドはIEnumerable<Entity>
、 などのさまざまなコレクション タイプや、一部のツールが返すカスタム タイプを取得できるようにList<Entity>
のみEntity[]
要求します。しかしList<Entity>
、すぐに呼び出し元を列挙可能な要素だけに制限しないように戻ります。たとえば、戻り値に対してすぐに Linq を使用できます。
単体テストのように、モック オブジェクトを作成し、残りのコードとの対話中にどのように動作するかを伝えることができるなど、さらに多くの利点があります。ただし、現在は仮想メソッドを持つクラスでこれを行うことができます。