Понимание слабой / плотной связи в «реальном мире»

Я не буду говорить, что такое «сообщество», потому что мне нужно непредвзятое объяснение, но, скажем, вы создаете модуль многократного использования, и этому модулю требуется более 3 зависимых модулей, и удаление одного из них приводит к ошибке не только в вашем приложении как Целый, который использует этот модуль, но сам модуль.

Насколько я понимаю (что должно быть неправильно), слабо связанная модульная система не сломается, просто удалив один модуль. Приложение по-прежнему должно работать, но без этой «функции» / модуля, а сам модуль не должен заставлять все работать не просто потому, что зависимый модуль не существует.

Это неправильно? Если так, то если модули все еще зависят от того, что все не работает, какая разница между жесткой / слабой связью?

Не совсем - удаление модуля может привести к поломке системы. Идея слабосвязанных систем заключается в том, что замена совершенно другого модуля будет работать прекрасно, если новый модуль соответствует тем же требованиям интерфейса, что и старый. Если бы он был тесно связан, окружающий код делал бы предположения о внутренностях и начинал бы терпеть неудачу, если был введен новый модуль.

Слабая связь по сути является косвенной зависимостью между модулями от того, как они могут развиваться.

Как правило, когда есть тесно связанные системы, различные модули / объекты имеют очень специфическое поведение, которое предполагает такое поведение периферийных объектов. Такие объекты связаны / связаны с поведением других модулей, и их нельзя использовать повторно отдельно или в каком-либо другом контексте.

Такие модули, даже если они отвечают за отдельные функции, не могут развиваться независимо или не могут развиваться

Пример:

Допустим, у вас есть 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. 
}

По сути, здесь функция draw выбирает прямоугольник, в котором нужно рисовать объекты. Это легко понять (люди могут назвать этот простой ) код. Тем не менее, это чрезвычайно связанный код.

Представьте себе ситуацию:

• Что делать, если механизм холста окон больше не является прямоугольником?
• Что, если есть дополнительные смещения, которые Canvas хранит, которые являются частными ?
• Что если какое-то другое приложение хочет такой же формы, но больше не имеет окна с графическим интерфейсом (например, оно создает изображения и сохраняет их в файлах).

Основной причиной проблемы является то, что объект shape знает и, следовательно, тесно связан с Canvas.

Что желательно, чтобы набор пикселей был задан в форме, где он пишет; shapeне должно быть (даже неявной) знания о том, где пиксели на самом деле написано.

Это зависит даже от того, что вы указываете в качестве модуля. Некоторые части системы должны быть тесно связаны (например, ваши сущности должны повторно использоваться во всем приложении), но некоторые системы должны быть свободными, либо с разделением интерфейса, либо, если мы говорим о том, чтобы не сломать приложение, если вы удалите модуль Затем этот модуль должен быть подключен как-то динамически, возможно, через контейнер IoC или что-то еще.

Кроме того, тесная связь означает, что некоторая часть зависит от конкретной реализации модуля, а не от определения модуля или чего-то еще.