「現実の世界」における疎結合/密結合の理解

公平な説明が欲しいので「コミュニティ」とは言いませんが、再利用可能なモジュールを作成していて、そのモジュールに3つ以上の依存モジュールが必要で、そのうちの1つを削除すると、アプリとしてだけでなく、このモジュールを使用する全体ですが、モジュール自体です。

私の理解（これは間違っているに違いない）から、疎結合のモジュラーシステムは、1つのモジュールを削除するだけでは壊れません。アプリは引き続き実行する必要がありますが、その「機能」/モジュールがなくても、依存するモジュールが存在しないために、モジュール自体がすべてを実行してはなりません。

これは間違っていますか？もしそうなら、モジュールがまだ機能していないすべての点に依存している場合、密結合と疎結合の違いは何ですか？

完全ではない---モジュールを削除すると、システムが壊れる可能性があります。疎結合システムの背後にある考え方は、新しいモジュールが古いモジュールと同じインターフェース要件に準拠している限り、完全に異なるモジュールでのスワップは問題なく機能するということです。それが密結合されている場合、周囲のコードは内部について推測を行い、新しいモジュールが導入されると失敗し始めます。

疎結合とは、基本的に、モジュールの進化方法に関するモジュール間の間接的な依存関係です。

一般に、緊密に結合されたシステムがある場合、さまざまなモジュール/オブジェクトには、周辺オブジェクトの動作を想定した非常に特定の動作があります。そのようなオブジェクトは他のモジュールの動作にリンク/結合されており、それらを単独でまたは他のコンテキストで再利用することはできません。

個々の機能を担当するモジュールが独立して進化できない、または進化できない場合でも、このようなモジュール

例：

3つのオブジェクト Shape（モデルオブジェクト）とCanvas（UI要素）があるとします。今

メソッドshape.draw(Canvas)がキャンバスの平面によって提供される平面上にオブジェクトを描画すると想定します。

現在、ウィンドウの一部が覆われ、サイズが変更される場合があります。そのような場合、上記のメソッドはこのようなことをするだけかもしれません。

shape::draw(Canvas) {
   Rect.WindowLeft = Canvas.GetWindowRect.getLeftOffset(); 
   Rect.LeftPixel = Canvas.GetWindowRect.pixels() + Rect.WindowLeft; 
   ....  // like this get all co-ordinates. 

   draw_instance(Rect);  // This will draw the actual shape. 
}

基本的に、ここでは、ドロー関数は、物事を描画する必要がある長方形をピックアップします。これは理解しやすい（人々はこの単純なと呼ぶかもしれません）コードです。ただし、これは非常に結合されたコードです。

状況を想像してみてください：

• キャンバスのウィンドウを保持するメカニズムが長方形ではなくなった場合はどうなりますか？
• Canvasが保持する追加のオフセットがプライベートである場合はどうなりますか？
• 他のアプリケーションが同じ形状を必要としているが、GUIウィンドウがなくなった場合（たとえば、画像を作成してファイルに保存している場合）はどうなるでしょうか。

この問題の根本的な原因は、オブジェクトがをshape 知っているため、と密に結合していることCanvasです。

ピクセルセットは、それが書き込む場所の形状に与えられることが望ましい。shapeピクセルが実際に書き込まれる場所に関する（暗黙的な）知識があってはなりません。

モジュールとして何を指定するかによっても異なります。システムの一部は緊密に結合されている必要があります（たとえば、エンティティはアプリ全体で再利用される必要があります）が、一部のシステムは、インターフェイスが分離されているか、モジュールを削除してもアプリケーションが壊れないことについて話している場合、緩いはずです、そのモジュールはおそらく動的に、おそらくIoCコンテナーなどを介して配線する必要があります。

また、密結合とは、一部がモジュールの定義ではなく特定のモジュール実装に依存することを意味します。