私たちは中規模プロジェクト (6 か月以上、開発者 3 名) に取り組んでおり、次の決定を行う必要があります。インターフェイスを具体的な実装から分離したいと考えています。1 つ目は、インターフェイスを別のファイルに保存することです。
さらに進んで、データをさらに分離します。1 つの .CS ファイルにインターフェイスを含む 1 つのプロジェクト (CSPROJ) と、ヘルプ クラス (このインターフェイス内で使用されるいくつかのパブリック クラス、いくつかの列挙型など) を含む別の .CS ファイルを作成します。次に、ファクトリ パターン、具体的なインターフェイス実装、およびその他の「ワーカー」クラスを含む別のプロジェクト (CSPROJ) を作成します。
このインターフェースを実装するオブジェクトを作成するクラスには、実装自体ではなく、インターフェースとパブリック クラスを含む最初のプロジェクトを含める必要があります。
このソリューションには 1 つの大きな欠点があります。それは、すべての「通常の」プロジェクトに対して、インターフェイスを持つプロジェクトが 1 つ、実装を持つプロジェクトが 1 つあるため、アセンブリの数が 2 倍になることです。
どのようなことをお勧めしますか? 1 つのインターフェースを独自のプロジェクトに配置するのではなく、すべてのインターフェースを 1 つの別のプロジェクトに配置するのが良いと思いますか?
ベストアンサー1
私は次のようにインターフェースを区別します。
スタンドアロンインターフェースプロジェクトの残りの部分について説明しなくても、その目的を説明できるもの。これらを 1 つの専用の「インターフェイス アセンブリ」に配置します。このアセンブリは、プロジェクト内の他のすべてのアセンブリによって参照される可能性があります。一般的な例:
ILogger
、、IFileSystem
。IServiceLocator
クラス結合インターフェースこれらは、実際にはプロジェクトのクラスのコンテキストでのみ意味を持ちます。これらを、結合されているクラスと同じアセンブリに配置します。
例: ドメイン モデルに
Banana
クラスがあるとします。IBananaRepository
インターフェイスを通じてバナナを取得する場合、そのインターフェイスはバナナに密結合されます。バナナについて何も知らないと、インターフェイスを実装したり使用したりすることは不可能です。したがって、インターフェイスが と同じアセンブリに存在するのは当然ですBanana
。前の例には技術的な結合がありますが、その結合は論理的なものに過ぎない可能性があります。たとえば、インターフェース宣言に への技術的なリンクがない場合でも、
IFecesThrowingTarget
インターフェースは クラスの協力者としてのみ意味をなす場合があります。Monkey
Monkey
私の答えは、いくつかのクラスへの結合。隠蔽すべてインターフェースの背後に隠すのは間違いです。時にはクラスを「新しくする」だけでもいいファクトリ経由で注入または作成するのではなく、