この状況で、インターフェイスがインターフェイスに依存することは問題ありませんか？
背景
別のプロジェクトでICircularBufferという循環バッファ用に定義されたインターフェイスがあります。このICircularBufferは私たちがいたるところで使用しているものなので、CommonInterfacesプロジェクトにあります。
さて、いくつかの非常に異なる機器を制御する別のインターフェースIEquipmentControllerがあります。この機器はいくつかのデータを生成します。バッファをIEquipmentControllerに渡して、渡したスレッドからの参照によってバッファを非同期に読み取ることができるようにします。
問題は、IEquipmentControllerとICircularBufferが2つの別々のプロジェクトで定義されていることです。だからこれは私の質問に私を導きます...
質問
CommonInterfacesは至る所でどのように使用されているので、私のIEquipmentControllerのプロジェクトがCommonInterfacesプロジェクトに依存することは問題ありませんか？
または
たぶん、具体的なEquipmentControllerにCommonInterfaces...への依存関係をとらせてから、IEquipmentControllerにバッファにアクセスするメソッドを定義させることができますか？したがって、実装の詳細を知らないままです（そして参照による受け渡しを完全に避けます）？この方法では、2つのインターフェース（IEquipmentControllerとICircularBuffer）が結び付けられないでしょう。
ここでの私の最善の選択肢は何ですか？そして、一般的に、インターフェイスが別のインターフェイスにアクセスするためだけに別のプロジェクトに依存することが良い考えである状況はありますか？
このタイプの依存関係には2つのオプションがあります。
インターフェイスの依存関係
バッファを受け入れるコントローラインターフェイスでメソッドを定義できます。これにより、モジュール間の結合が増加し、mayは、依存関係とコード変更に関して波及効果があります。既存の実装は更新する必要があり、バッファを気にしない可能性があります。
すべてのサブクラスでバッファを使用できますか？ 「バッファーの使用」はコントローラーの機能の一部ですか？もしそうなら、これは理にかなっているかもしれません。
コンストラクターの依存関係
インターフェイスはそのままにして、バッファを実装のコンストラクタに渡します。これにより、モジュールの結合や既存のクラスの更新が回避されます。
特定の実装のみがバッファを処理する場合、またはモジュール間の変更を制限する必要がある場合、これはより強力なソリューションです。
CommonInterfacesはあらゆる場所でどのように使用されているので、IEquipmentControllerのプロジェクトがCommonInterfacesプロジェクトに依存することは問題ありませんか？
もちろん。これが、CommonInterfacesのようなプロジェクトの要点です。これらのインターフェイスをさまざまなプロジェクトで自由に再利用できるようにする必要があります。
ただし、より一般的なインターフェースを返すことを検討することをお勧めします。プロジェクトの依存関係を避けたいからではなく、実装の詳細が漏れないようにしたいからです。 IEquipmentControllerのユーザーは、ICircularBufferを使用していることを本当に知る必要がありますか？ ICircularBufferはおそらくIListを実装します（または実装する必要があります）。おそらく、代わりにバッファをリストとして返すのが理にかなっています。