Розуміння вільної / тісної зчеплення в "реальному світі"

Я не хочу сказати, що таке "спільнота", тому що я хочу необ'єктивне пояснення, але скажімо, що ви будуєте модуль багаторазового використання, і для цього модуля потрібні 3+ залежні модулі, і вилучення 1 з них спричиняє помилку злому не лише у вашому додатку як Ціле, яке використовує цей модуль, але сам модуль.

З мого розуміння (що, мабуть, неправильно), модульна система, що зв'язана, не зламається, просто видаливши один модуль. Додаток все одно повинен працювати, але без цієї "функції" / модуля, а сам модуль не повинен спричиняти запуск всього просто тому, що залежного модуля не існує.

Це неправильно? Якщо так, якщо модулі все ще залежать від того, що все не працює, яка різниця між герметичною / нещільною муфтою?

Не зовсім --- видалення модуля цілком може зламати систему. Ідея, що стоїть за слабко пов'язаними системами, полягає в тому, що заміна в абсолютно іншому модулі працюватиме чудово, доки новий модуль відповідає тим же вимогам інтерфейсу, що і старий. Якби він був щільно з'єднаний, навколишній код робив би припущення про внутрішні системи і починав би виходити з ладу, якби був введений новий модуль.

Вільне з'єднання - це по суті опосередкована залежність між модулем від того, як вони можуть розвиватися.

Як правило, коли існує щільно пов'язана система, різні модулі / об'єкти мають дуже специфічну поведінку, яка передбачає таку поведінку периферійних об'єктів. Такі об'єкти пов'язані / пов'язані з поведінкою інших модулів, і їх не можна повторно використовувати ізольовано або в будь-якому іншому контексті.

Такі модулі, незважаючи на те, що відповідають за окремі функціональні можливості, не можуть еволюціонувати самостійно або не можуть розвиватися

Приклад:

Скажімо, у вас є 3 об’єкти Shape(об’єкт моделі) та Canvas(елемент інтерфейсу). Тепер

Припустимо, що метод 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, які є приватними ?
• Що робити, якщо якась інша програма хоче такої ж форми, але більше не має вікна графічного інтерфейсу (наприклад, це створення зображень та збереження у файлах).

Першопричиною проблеми є те, що об'єкт shape знає і, отже, щільно поєднується з Canvas.

Що бажано, щоб набір пікселів був наданий формі, де він пише; shapeне повинно бути (навіть неявній) знання про те, де пікселі на насправді написано.

Це залежить навіть від того, що ви вказали як модуль. Деякі частини системи повинні бути щільно з'єднані (наприклад, ваші особи повинні бути повторно використані у всьому додатку), але деякі системи повинні бути вільними, або з розділенням інтерфейсу, або якщо ми говоримо про те, щоб не порушити додаток, якщо ви видалите модуль , тоді цей модуль потрібно якось динамічно підключати, можливо через контейнер IoC чи щось інше.

Крім того, щільне з'єднання означає, що якась частина залежить від конкретної реалізації модуля, а не від визначення модуля чи чогось іншого.