私はLooseCouplingとその利点を読んでいましたが、これは本当に良いことですが、緩く結合されたソリューションを作成するのにどのツールが優れているのか疑問に思い始めました。最初に頭に浮かんだのはTypeandInterfacesとAbstractクラスですが、緩い結合を提供する方法はたくさんあると確信しています。多分、ポリモーフィズムは、ゆるく結合されたオブジェクトとシステムを作成するのに役立ちます。
ありがとう。
私はLooseCouplingとその利点を読んでいましたが、これは本当に良いことですが、緩く結合されたソリューションを作成するのにどのツールが優れているのか疑問に思い始めました。最初に頭に浮かんだのはTypeandInterfacesとAbstractクラスですが、緩い結合を提供する方法はたくさんあると確信しています。多分、ポリモーフィズムは、ゆるく結合されたオブジェクトとシステムを作成するのに役立ちます。
ありがとう。
これは非常に幅広い質問です-おそらく答えるには広すぎます。
ただし、「緩い結合」を使用したソリューションを提供できる2つの方法は次のとおりです。
依存性注入
依存性注入(特に制御の反転コンテナを使用する場合)は、アプリケーションまたはソリューション内で緩い結合を提供します-依存性注入では、依存オブジェクトへの参照をハードコーディングせず、代わりにインターフェイスにコーディングし、それらのインターフェイスの実装を注入します。
これは、ILoggerインターフェースを実装するアプリケーションのLoggingコンポーネントの簡単なコード例です。
public class ConcreteLogger : ILogger
{
public LogMessage(string message)
{
Log.Write(message);
}
}
次に、クラスの1つが、ロガーインターフェイスのこの具体的な実装を受け取ります。
public class MyClass
{
private ILogger logger;
public myClass(ILogger logger)
{
this.logger = logger;
}
public void DoSomething()
{
// Now if DoSomething needs to call logging it can call what ever ILogger was passed in
this.logger.Log("We did something");
}
}
サービス指向
サービス指向は、ソリューションの異なるサブシステム間の緩い結合を提供します-サービス指向を使用すると、ソリューションの各部分は、公開およびインターフェース(多くの場合、メッセージングベースのインターフェース)を行う独自のスタンドアロンサービスになります。
つまり、たとえばソリューションのShippingサブシステムと通信する必要がある場合、アプリケーションはシステムインターフェイスとそのアドレスについてのみ知る必要があり、内部実装については何も知る必要はありません。これは、基本的なOOの原則のより広範なアプリケーションとほぼ見なすことができます。
これらは両方とも2つの異なるタイプの緩い結合を提供します(これはあなたの質問の問題の1つであり、それ自体の用語は緩く定義されています)
おそらくあなたの脳は?
インターフェイスを念頭に置いてプログラムします。最小限の明示的なインターフェイスを備えた自己完結型コードの小さな島としてライブラリを構築します。すべてのシンボル、特に可変シンボル(変数など)のスコープを制限します。関連性がない限り、実装の詳細を公開しないでください。
他の人はすでに素晴らしい答えを提供していますが、私は1つの考えを追加したいと思います:継承を使用して実装されたポリモーフィズムは緩い結合を促進しません。継承は、基本クラスと派生クラスの間の非常に強力な結合です。
MEFは緩い結合に最適なツールです!アプリを最初から非常にMEF/プラグインに対応するように設計すると、アプリの結合が非常に緩くなることがわかります。
結合を緩めるための優れた方法は、依存性注入です。
これまでで最高のツールはMicrosoftCAB(前述のUnityフレームワークを含む)
です。これには、依存性注入、疎結合イベント処理などのツールが含まれています。