別のライブラリに依存するインターフェイスを定義するライブラリを作成するのは悪い習慣ですか?
密結合が良くないことはわかっていますが、.NET クラスを使用する場合にもこれは当てはまりますか?
たとえば、.NET では、Color オブジェクトを返すライブラリがある場合、そのライブラリを使用するものはすべて System.Drawing に依存することになります。ライブラリ内に独自の Color 型クラスを作成したほうがよいでしょうか?
別のライブラリに依存するインターフェイスを定義するライブラリを作成するのは悪い習慣ですか?
密結合が良くないことはわかっていますが、.NET クラスを使用する場合にもこれは当てはまりますか?
たとえば、.NET では、Color オブジェクトを返すライブラリがある場合、そのライブラリを使用するものはすべて System.Drawing に依存することになります。ライブラリ内に独自の Color 型クラスを作成したほうがよいでしょうか?
VolatileとStable Dependenciesを区別します。
一般に、Color は既に BCL にあり、本質的に決定論的であり、リソースを大量に消費するアウトプロセス通信を伴わず、実行の特定のセットアップに依存しないため、安定した依存関係のように見えます。時間環境。
ここでの唯一の考慮事項は、Color に関して言えば、BCL にそのようなクラスが複数あるということです。そのため、WPF には Color の独自の定義があるため、API で Windows フォーム アプリケーションのみをターゲットにすることを本当に意図していることを確認してください。
UI の一部を特定の色でペイントするために Color が必要な場合は、おそらく組み込みの Color クラスで問題ありませんが、Color がドメイン モデルの主要な概念であり、別の UI (WPF、 Windows フォーム、Web) は、独自の抽象化を定義する方がよいでしょう。
このようなより高度なケースでは、後で抽象化の周りにアダプタとマッパーを作成して、抽象化と具体的な Color クラスの間のギャップを埋めることができます。
標準の .NET ライブラリであれば、気にする必要はありません。あるクラスから別のクラスにマップする理由はありません...次の .NET リリースで System.Color が変更されたらどうなるでしょうか? マッピングコードも変更する必要があり、おそらくバージョンを検出してそれに応じてマップする必要があります。それは本当に苦痛です。
すべてのライブラリで、ライブラリ内のもののみに依存するオブジェクトを返します。
暗黙的ではない別の名前空間に依存するライブラリを作成した理由を自問しました。「カプセル化」の概念全体に反しているようです。
したがって、私自身の推論と OOP の知識から外れただけで、独自の非依存オブジェクトを返すという正しい方向に進んでいると言えます。
あなたは素晴らしい質問をします。答えは、場合によります。常に利用可能な標準ライブラリの場合は問題ありません。コア ライブラリは常に異なる .DLL を参照します。
サードパーティのライブラリの場合、問題が発生します。他のライブラリが必要な場合に自分で作成するのは必ずしも良い考えではありませんが、その場合、別のライブラリに依存することになります。これは、ユーザーにとって論理的な問題です。
ここに正解はありません。プロジェクトにとって最も理にかなった方法を選択する必要があります。はい、可能な限り分離するようにしてください。
クラスの使用状況によって異なります。
Color クラスのインスタンスからシステム Color クラスのインスタンスを取得する必要がある場合 (たとえば、Windows フォームに描画する場合)、System クラスを使用することをお勧めします。 2 つの型の間で変換すると、Color クラスのすべての「機能」を無料で使用できるという利点が得られます (「赤」、「黒」、「緑」などの組み込み定数など...
一方、任意の RGB 値を (おそらく科学計算のために) 操作するだけで、System.Color のインスタンスに変換する必要がない場合は、独自のクラスを作成するのが理にかなっています。
おそらく、 System.Color クラスを使用する方が良いでしょう - はい、カプセル化とそれはすべて良い考えですが、膨大な時間を節約することを犠牲にすることはありません!
.NET コア ライブラリで何かを使用することについて心配する必要はありません。それなしでは DLL を書くことはできません。.NET 4 にはクライアント プロファイル インストーラーがあり、基本的にこのインストーラーを使用すると、クライアントで使用されると予想されるもののみがインストールされると思われるため、注意が必要な唯一の場所は System.Web 名前空間です。個人的には、ダウンロード時間を少し節約するために不必要な複雑さを追加するだけなので、Microsoft 側では悪い考えだと思います。