インターフェイスベースのプログラミング、私はそれを正しくやっていますか？

Question

OKだから私のコードベースでインターフェイスを使い始めることにしました。これは特定のタスクではうまく機能します。例えば、私はIUrlBuilderを実装するURLビルダークラスを持っていますが、実装は関係ありません。ブリリアントですが、例えばこのインタフェースを利用してください。

namespace SproutMessagingFramework.Webtext.Interfaces 
{ 
using System.Net; 

public interface ICookieJar 
{ 
    CookieCollection Collection { get; set; } 
    CookieContainer Container { get; set; } 

    void AddResponse(HttpWebResponse Response); 
    void AddResponse(HttpWebResponse Response, string Path, string Domain); 
} 
} 

私の見解では、このインターフェースは、これらの2つの方法が文句を言わない、具体的なクラスがすでにやっているだろう何よりも他の多くをやっている、かなり具体的なです。それで私はなぜそれをインターフェイスにしましたか？私の考えは、AddResponseの実装を変更する必要がある場合はどうですか？

これが正しいのですか、それともコードベースが肥大化していますか？

Answer 1

インターフェイスは、特定のクラスと1対1の対応関係で設計できます。これにより、（とりわけ）モックフレームワークとの統合が可能になります。ここでは、テスト環境でクッキーモンスターの動作を検証しながら、実際のものにふさわしいクッキージャーを置き換えます。

しかし、インターフェースがクラスの機能のサブセットを定義するのがより一般的であり、しばしばクラス自体に対して意図的に直交することがあります。直交インタフェースの良い例はIDisposableです。リソースクリーンナップはクラスが実際に設計されているものではありませんが、ソケット、ファイル記述子などの管理されていないリソースのクリーンな再利用をサポートする場合は、クラスはIDisposableを実装します。

もう1つの一般的な使用方法は、ICollectionやIEnumerableなどの統一されたコンテナモデルを提供することです。

最後に、クラスは通常、いくつかのインターフェイスを実装しています。通常、これらのインターフェイスは、機能の直交断面に対応しています。

Answer 2

AddResponseメソッド自体を実装する方法が1つしかない場合でも、インターフェイスの具体的なインスタンスにコールを転送する前に何かを行うICookieJarの実装を想像することはできます。

たとえば、診断ログを追加する実装、または保存されているときにCookieの名前を透過的に変更する実装。