具体的なクラスに直接ではなく、インターフェイスに対するプログラミングを推奨するのはいつですか?
私が従うガイドラインは、コードが論理的/物理的境界を越える必要があるときはいつでも抽象化を作成することです。特にインフラストラクチャ関連の問題が関係している場合はそうです。
もう 1 つのチェックポイントは、追加の懸念コード (キャッシュ、トランザクション認識、インプロセス実行ではなく Web サービスの呼び出しなど) が原因で、依存関係が将来変更される可能性があるかどうか、またはそのような依存関係がインフラストラクチャ統合ポイントへの直接参照を持っているかどうかです。
コードが、論理的/物理的境界を越えるための制御を必要としないものに依存している場合、多かれ少なかれそれらと対話するための抽象化を作成しません。
何か不足していますか？
また、次の場合にインターフェイスを使用します。
複数のオブジェクトを特定の方法で処理する必要がありますが、それらは基本的に関連していません。ビジネス オブジェクトの多くは、特定のユーティリティ オブジェクトにアクセスする可能性があります。その場合、ユーティリティ オブジェクトが特定のメソッドを呼び出せるように、そのユーティリティ オブジェクトへの自身の参照を与える必要があります。そのメソッドをインターフェイスに入れ、そのインターフェイスをそのユーティリティ オブジェクトに渡します。
インターフェイスをパラメーターとして渡すことは、単体テストで非常に役立ちます。特定のインターフェースを備えたオブジェクトのタイプが 1 つしかないため、定義済みのインターフェースが実際には必要ない場合でも、単体テストでそのオブジェクトを「偽造」するためだけにインターフェースを定義/実装することがあります。
最初の 2 つの箇条書きに関連して、Observer パターンとDependency Injectionを確認してください。これらのパターンを実装するように言っているわけではありませんが、インターフェイスが本当に役立つ場所のタイプを示しています。
これに関するもう 1 つのひねりは、SOLID プリンシパル、Open Closed プリンシパル、およびInterface Segregation 原則の 2 つを実装するためのものです。前の箇条書きのように、これらのプリンシパルをどこにでも (少なくともすぐに) 厳密に実装することにストレスを感じないでください。ただし、これらの概念を使用して、どのオブジェクトがどこに行くかということから離れて、コントラクトと依存関係についてより深く考えるようにします。
最後に、あまり複雑にしすぎないようにしましょう。私たちは .NET の厳密に型指定された世界にいます。メソッドを呼び出すか、プロパティを設定する必要があるが、渡す/使用するオブジェクトが根本的に異なる可能性がある場合は、インターフェイスを使用します。
コードが別のライブラリによって参照される予定がない場合 (少なくともしばらくの間)、特定の状況でインターフェイスを使用するかどうかの決定は、責任を持って後回しにすることができます。「インターフェースの抽出」リファクタリングは、最近では簡単に実行できます。私の現在のプロジェクトでは、インターフェイスに切り替える必要があるかもしれないと考えているオブジェクトが渡されています。私はそれについて強調していません。
インターフェイスの抽象化は、単体テストを行うときに便利です。テストオブジェクトのモック作成に役立ちます。これは、データベースのデータを実際に使用せずに開発するためのTDDで非常に役立ちます。
インターフェイスにないクラスの機能が必要ない場合は、なぜ常にインターフェイスの実装を好まないのでしょうか?
これにより、コードを将来変更しやすくなり、テスト (モック) が容易になります。
あなたはすでに正しい考えを持っています。私はこれにいくつかのメモを追加するだけです...
まず、抽象化は「インターフェース」を意味しません。たとえば、「接続文字列」は単なる文字列ですが、抽象化されています...問題の「タイプ」ではなく、その使用の意図に関するものです。
次に、何らかのテストの自動化を行っている場合は、テストを作成することで明らかになる苦痛と摩擦を探します。テストのためにあまりにも多くの外部条件を設定しなければならないことに気付いた場合、それは、テストするものとそれが相互作用するものとの間に、より良い抽象化が必要であることを示しています。
よく言ったと思います。これの多くは文体的なものになります。私が見たオープン ソース プロジェクトでは、すべてにインターフェイスと実装があり、ちょっとイライラしますが、オブジェクトの実装は壊れる可能性がありますが、ダミーはまだ機能するため、反復開発が少し簡単になる可能性があります。finalしかし、正直なところ、継承によってキーワードを使いすぎないクラスはダミーにすることができます。
私はあなたのリストにこれを追加します: ブラックボックスと考えられるものはすべて抽象化する必要があります. これには、あなたが言及したもののいくつかが含まれますが、さまざまな状況でさまざまな利点を持つ複数の有用な実装を持つ可能性が高い毛むくじゃらのアルゴリズムも含まれます。
さらに、インターフェースは、複合オブジェクトで非常に頻繁に役立ちます。これは、Java のスイング ライブラリのようなものが何かを成し遂げる唯一の方法ですが、よりありふれたオブジェクトにも役立ちます。ValidityChecker(私は個人的に、and-compose または or-compose 下位 s の方法のようなインターフェイスを持つことを好みますValidityChecker。)
Interface を渡すことで得られる便利な機能のほとんどは、既に述べたとおりです。ただし、次のように追加します。