Когда улучшение согласованности программ ухудшает сцепление?

Question

Недавно я сдал экзамен по принципам и шаблонам проектирования, и один из вопросов на экзамене был следующим: "Иногда улучшение сплоченности программы может ухудшить сцепление, приведите пример".

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

Связь - это уровень зависимости между многими классами / модулями. Это означает, что хороший класс / модуль будет работать независимо от того, вносим ли мы значительные изменения в другой модуль / класс.

Пример, который я использовал для себя, - вот пример: работа бармена - приготовление кофе и других напитков. Хороший бармен должен выполнять свою работу, которая делает указанный кофе, и это повышает его сплоченность, но если он начинает мыть пол и обслуживает клиентов, он отрывается от своей работы, и, следовательно, сплоченность теряется. Хороший бармен также не должен подвергаться влиянию других сотрудников, а это означает, что его связь невелика. Другими словами, если уборщица не появляется на работе однажды утром, его работа не должна быть затронута.

Поэтому, если мое понимание верно, это означает, что увеличение сплоченности не должно оказывать негативного влияния на сцепление, точно так же, как указание бармену сосредоточиться на кофе больше не сделает его более зависимым от уборщицы.

Я что-то пропустил? Мое понимание сплоченности / сцепления неверно? Извините за долгое чтение!

Answer 1

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

Конечно, зная рабочие места друг друга, персонал теперь более тесно связан. Это может означать, что любое изменение в процессе затронет больше людей и создаст проблему обучения. Например, если бар решит перейти с кубикового льда на колотый лед, управляющему придется сказать об этом, иначе он может получить неправильный вид льда. Если бы команда была слабо связана, только бармен должен был бы знать.

Из этого примера вы можете видеть, что очень сплоченная команда должна знать рабочие места друг друга, что затрудняет изменение любой отдельной работы. Это соответствует проблеме ремонтопригодности, создаваемой тесно связанными модулями в программном обеспечении. Это удобно и позволяет модулям работать более тесно вместе, но создает проблему, если что-то изменится.