疎結合

コンピューティングとシステム設計において、疎結合システムとは

1. コンポーネントは互いに弱く関連付けられており (関係が壊れやすい)、1 つのコンポーネントの変更が別のコンポーネントの存在やパフォーマンスにほとんど影響を与えません。
2. 各コンポーネントが他の個別のコンポーネントの定義をほとんどまたは全く知らない、あるいは使用しないシステム。サブ領域には、クラス、インターフェース、データ、およびサービスの結合が含まれます。 ^[1]疎結合は密結合の反対です。

疎結合システムのコンポーネントは、同じサービスを提供する代替実装に置き換えることができます。疎結合システムのコンポーネントは、同じプラットフォーム、言語、オペレーティング システム、またはビルド環境への制約があまりありません。

システムが時間的に分離されている場合、トランザクションの整合性も提供することが難しく、追加の調整プロトコルが必要になります。異なるシステム間でのデータ複製は疎結合（可用性）を提供しますが、一貫性（データ同期）の維持に問題が発生します。

より広範な分散システム設計における疎結合は、トランザクション、メッセージ指向ミドルウェアによって提供されるキュー、および相互運用性標準の使用によって実現されます。^[2]

疎結合を促進する4つのタイプの自律性は、参照自律性、時間自律性、フォーマット自律性、プラットフォーム自律性である。^[3]

疎結合は、サービス指向アーキテクチャにおけるアーキテクチャ原則および設計目標です。11種類の疎結合とそれに対応する密結合が以下にリストされています。^[4]

• 仲介者を介した物理的な接続、
• 非同期通信スタイル、
• データモデル内の単純な共通型のみ、
• 弱い型システム、
• データ中心かつ自己完結型のメッセージ
• プロセスロジックの分散制御、
• 動的バインディング（サービスコンシューマとプロバイダ）
• プラットフォームの独立性、
• システムレベルのトランザクションではなくビジネスレベルの補償
• 異なる時期に展開し、
• バージョン管理における暗黙的なアップグレード。

エンタープライズ サービス バス(ESB) ミドルウェアは、多次元での疎結合を実現するために発明されました。^[5]しかし、過剰に設計され、誤った位置に置かれた ESB は逆の効果をもたらし、望ましくない密結合と中央のアーキテクチャ ホットスポットを生み出す可能性もあります。

イベント駆動型アーキテクチャは疎結合を促進することも目的としている。^[6]

データを標準形式 ( XMLやJSONなど) で公開することで、インターフェースの疎結合を強化できます。

プログラム コンポーネント間の疎結合は、パラメータで標準データ型を使用することで強化できます。カスタマイズされたデータ型またはオブジェクトを渡すには、両方のコンポーネントがカスタム データ定義を認識している必要があります。

サービスの疎結合は、サービスに渡される情報をキー データに減らすことによって強化できます。たとえば、手紙を送るサービスは、顧客 ID だけが渡され、顧客アドレスはサービス内で取得される場合に最も再利用しやすくなります。これにより、サービスを特定の順序で呼び出す必要がないため (GetCustomerAddress、SendLetter など)、サービスが分離されます。

結合とは、あるコンポーネントが他のコンポーネントについて持つ直接的な知識の度合いを指します。コンピューティングにおける疎結合は、カプセル化と非カプセル化として解釈されます。

密結合の例としては、依存クラスに必要な動作を提供する具象クラスへの直接ポインターが含まれている場合が挙げられます。依存クラスを変更せずに、依存関係を置き換えたり、その「シグネチャ」を変更したりすることはできません。疎結合は、依存クラスにインターフェイスへのポインターのみが含まれており、そのインターフェイスを 1 つまたは複数の具象クラスで実装できる場合に発生します。これは、依存関係の逆転と呼ばれます。依存クラスの依存関係は、インターフェイスによって指定された「コントラクト」、つまり実装クラスが提供する必要があるメソッドやプロパティの定義済みリストです。したがって、インターフェイスを実装するクラスは、クラスを変更することなく、依存クラスの依存関係を満たすことができます。これにより、ソフトウェア設計の拡張が可能になります。インターフェイスを実装する新しいクラスは、依存クラスを変更することなく、一部またはすべての状況で現在の依存関係を置き換えるように記述できます。新しいクラスと古いクラスは自由に交換できます。密結合では、これは許可されません。

これは、必要な動作を提供する依存クラスと一連の具体的なクラス間の疎結合 の例を示すUML図です。

比較のために、次の図は、依存クラスとプロバイダー間の 強い結合を備えた代替設計を示しています。

関数をコアモジュールとする概念 (関数型プログラミングを参照) または関数をオブジェクトとする概念を持つコンピュータプログラミング言語は、疎結合プログラミングの優れた例です。関数型言語には、継続、クロージャ、またはジェネレータのパターンがあります。関数型プログラミング言語の例については、 ClojureとLisp を参照してください。SmalltalkやRubyなどのオブジェクト指向言語にはコードブロックがありますが、Eiffel にはエージェントがあります。基本的な考え方は、他の囲む概念とは独立して関数をオブジェクト化 (オブジェクトとしてカプセル化) することです (たとえば、オブジェクト関数を囲むオブジェクトの直接的な知識から切り離すなど)。ファーストクラス関数の 1 つの形式として適格なオブジェクトとしての関数の詳細については、 ファーストクラス関数を参照してください。

たとえば、オブジェクト指向言語では、オブジェクトの関数がオブジェクトとして参照されると (その関数は、その外側のホスト オブジェクトに関する知識を持たずに済みます)、新しい関数オブジェクトを渡したり、保存したり、後で呼び出すことができます。これらの関数オブジェクトが渡される受信オブジェクトは、外側のホスト オブジェクトに関する直接の知識がなくても、自分の都合の良いときに、含まれている関数を安全に実行 (呼び出し) できます。このようにして、プログラムは、外側のホスト オブジェクトへの直接参照から安全に切り離された状態で、関数オブジェクトのチェーンまたはグループを実行できます。

電話番号は優れたアナログであり、この分離の程度を簡単に示すことができます。

たとえば、あるエンティティが特定の仕事を遂行するために別のエンティティに電話番号を提供します。その番号に電話がかかってくると、発信側のエンティティは事実上「この仕事をしてください」と言っていることになります。分離または疎結合はすぐに明らかになります。番号を受信するエンティティは、番号がどこから来たのか (番号の提供元への参照など) を知らない場合があります。一方、発信者は、誰に電話をかけているのか、どこにいるのか、通話の受信者が内部でどのように動作しているのかといった具体的な知識から分離されています。

この例をさらに一歩進めると、発信者は通話の受信者に「この作業をお願いします。終わったらこの番号に折り返し電話してください」と言うかもしれません。受信者に提供される「番号」は「コールバック」と呼ばれます。ここでも、この機能オブジェクトの疎結合または分離の性質が明らかです。コールバックの受信者は、何が、または誰が呼び出されているのかを認識していません。コールバックの受信者は、自分が電話をかけることができることと、いつ電話をかけるかを自分で決定することだけを認識しています。実際には、コールバックは、最初にコールバックを提供した人に対してではない可能性があります。このレベルの間接性により、関数オブジェクトは疎結合プログラムを実現するための優れたテクノロジとなっています。

疎結合コンポーネント間の通信は、前述の非同期通信スタイルや同期メッセージパッシングスタイルのような一連のメカニズムに基づいている可能性がある^[7]

疎結合の度合いは、送信システムまたは受信システムで発生する可能性のあるデータ要素の変更の数に注目し、コンピューターが引き続き正しく通信できるかどうかを判断することで測定できます。これらの変更には、次のような項目が含まれます。

1. メッセージに新しいデータ要素を追加する
2. データ要素の順序を変更する
3. データ要素の名前の変更
4. データ要素の構造の変更
5. データ要素の省略

• 連鎖的な失敗
• 凝集性（コンピュータサイエンス）
• コナセンス (コンピュータプログラミング)
• カップリング（コンピュータサイエンス）
• エンタープライズ サービス バス
• アプリケーションプログラミングインターフェース
• デメテルの法則
• 関心の分離
• サービス指向アーキテクチャ
• 宇宙ベースの建築(SBA)