他に使用できる可能性がある場合は、常にインターフェイスを作成する必要がありますか、それとも実際に必要になるまで待ってから、インターフェイスを使用するようにリファクタリングする必要がありますか？
インターフェイスへのプログラミングは一般的に適切なアドバイスのように思えますが、YAGNIがあります...
多分状況次第だと思います。現在、レシピやその他のフォルダーを含めることができるフォルダーを表すオブジェクトがあります。Folderを直接使用する代わりに、IContainerのようなものを実装することを心配する必要がありますか？将来、他のサブレシピを参照するレシピが必要な場合に備えて（たとえば、パイクラストレシピのコンテナでもあるアップルパイレシピ）
それは常に状況に依存します。インターフェイスを使用する別のクラスがあることがわかっている場合は、はい、後で時間を節約するためにインターフェイスクラスを作成します。ただし、確信が持てない場合（そしてほとんどの場合、確信が持てない場合）は、必要になるまで待ちます。
これは、インターフェイスの可能性を無視することを意味するわけではありません。後でインターフェイスを作成することを視野に入れて、オブジェクトのパブリックメソッドなどについて考えてください。ただし、実際には必要のないものでコードベースを乱雑にしないでください。
それを使用するテストは常にありますよね（ユニットテストを行いますね）。つまり、それを使用するのは常にN + 1クラスです。ここで、Nはアプリケーションでクラスを使用するクラスの数です。
依存性注入以外のインターフェースのもう1つの目的は、関心の分離であり、クラスが実際に複数のインターフェースを実装できるようにすることです。
そのすべてを念頭に置いてください。ただし、最初に実装されていない場合は、リファクタリングを介して後でいつでもインターフェイスを導入できます。
一般に、クラスが実際にテストされるまで発生しない実装の問題がある可能性があるため、1つのクラスのみが実装する場合は、インターフェイスの作成に煩わされることはありません。シナリオ。この場合、時期尚早に作成されたインターフェースにメンバーが多すぎるか、メンバーが欠落している可能性があります。
たとえば、.NET Framework Bas Class LibraryチームはICollection、プロパティが含まれている場合、時期尚早に設計することを認めていSyncRootます。後のジェネリックについては、ICollection<T>削除することにしました（http://blogs.msdn.com/bclteam/archive/2005/03/15/396399.aspx）。
同じインターフェースを実装するモックオブジェクトを作成する場合、それはインターフェースの作成を正当化する2番目の実装としてカウントされます。ただし、すべての単体テストでモックスタイルのインターフェイスが保証されるわけではありません。
それは、クラスを使用する場所の数に依存し、インターフェイスを実装する可能性のあるクラスの数には依存しないと思います。1つまたは2つの場所でのみフォルダを使用している場合は、インターフェイスが実際に必要になるまで待ってから、実装してリファクタリングしてください。ただし、Folderを100の異なる場所で使用する場合は、事前にインターフェイスにプログラミングすることで時間を節約できます。
インターフェイスは、セマンティクスまたは概念を定義するためのコントラクトと考えてください。これは一般的なアプローチであり、実際には言語固有ではありません。OOのコンテキストでは、単一の継承モデルで作業している場合、オブジェクトモデルを定義するためにクラスよりもインターフェイスを優先するための優れたケースがあります。これは、その単一のスーパークラスパスウェイが非常に貴重であり、オブジェクトまたはメソッドに公開されるプロパティを定義するよりも「実質的な」何か。
IContainerセマンティクス（コントラクト）を使用することは、フォルダーからインターフェイスを作成する理由としてはかなり不十分です。フォルダーを作成することをお勧めします（重要なロジックを実行している場合）。言語のコアフレームワークに（既存の可能性が高い）IContainerまたはICollectionインターフェイスを「実装」します。
いつものように、より良い選択は特定の問題にかなり依存しています。フォルダ（？！）でもあるレシピの場合、おそらく親子、つまり構成の関係を考えています。これは、システムに他の要素がある場合にインターフェイスを使用して表現できる（そして表現する必要がある）セマンティクスです。その種のセマンティクスを使用して構成されたものを「操作」します。
インターフェイスには（プログラミングに関して）少しオーバーヘッドがあります。WoofとIWoofのクラスとインターフェイスのセットだけを使い終わったときに、おそらく表現する必要がなかったことがわかります。インターフェイスに関する問題-単純なクラスで十分だったでしょう。
原則として、どのIでも、少なくとも2つの具象クラス（IImpl、または以外のより意味のある名前）が必要です。
お役に立てば幸いです。
多くの人がすでに非常に適切なアドバイスをまとめています。追加したいことの 1 つは、具象クラスへの直接的なハード依存を避けたい場合は、インターフェイスが疎結合を提供することで役立つということです。プラグイン ベースのアーキテクチャを作成している場合は、間違いなくインターフェイスが適しています。また、単体テストを並行して、または後で書くことを計画している場合は、フォルダー クラスを呼び出すコードが、呼び出し元のコードをテスト可能にするための具体的な実装を実行する必要があることに気付くでしょう。 . フォルダー クラスの具体的な実装が DB またはサービスと通信している場合は、それをテストにも引き継ぐ必要があり、すぐに扱いにくくなります。ちょうど私の2セント。