У меня проблемы с пониманием утверждения low in coupling and high in cohesion. У меня есть googled и много читал об этом, но все еще трудно понять.
Насколько я понимаю, High cohesion означает, что у нас должны быть классы, специализированные для выполнения определенной функции. Надеюсь, это правильно? Как класс проверки кредитной карты, который специализируется только для проверки кредитных карт.
И до сих пор не понимаю, что означает низкая связь?
Я верю в это:
Под связностью понимается степень, в которой элементы модуля/класса связаны друг с другом. Предполагается, что связанный код должен быть близок друг к другу, поэтому мы должны стремиться к высокой согласованности и связывать весь связанный код как можно ближе друг к другу. Это связано с элементами внутри модуля/класса.
Связывание относится к степени, в которой различные модули/классы зависят друг от друга. Предполагается, что все модули должны быть максимально независимыми, поэтому низкая связь. Это связано с элементами между различными модулями/классов.
Для визуализации всей картины будет полезно:
Скриншот был взят из Coursera.
Cohesion в разработке программного обеспечения, как и в реальной жизни, состоит в том, насколько элементы, состоящие из целого (в нашем случае пусть говорят класс), можно сказать, что они действительно принадлежат друг другу. Таким образом, это показатель того, насколько сильно связана каждая функциональность, выраженная исходным кодом программного модуля.
Один из способов взглянуть на сплоченность в терминах OO - это то, что методы в классе используют любые частные атрибуты.
Теперь обсуждение больше, чем High Cohesion (или наилучший тип сцепления - функциональная сплоченность), когда части модуля сгруппированы, потому что все они вносят вклад в одну четко определенную задачу модуля.
Связь в простых словах - это то, насколько один компонент (опять же, представьте, что класс, хотя и не обязательно) знает о внутренних действиях или внутренних элементах другого, то есть о том, сколько знаний у него есть другой компонент.
Свободная связь - это метод соединения компонентов в системе или сети, чтобы эти компоненты, по крайней мере, были практически возможными...
Я написал сообщение в блоге об этом. Он подробно обсуждает все это с примерами и т.д. Это также объясняет преимущества того, почему вы должны следовать этим принципам.
В разработке программного обеспечения высокая сплоченность означает, что класс должен хорошо выполнять одно и одно. Высокая сплоченность тесно связана с принципом единой ответственности.
Низкая связь предполагает, что класс должен иметь как можно меньше зависимостей. Кроме того, зависимости, которые должны существовать, должны быть слабыми, предпочитать зависимость от интерфейса, а не от конкретного класса, или композицию, а не наследование.
Высокая когезия и низкая связь дают нам лучше разработанный код, который легче поддерживать.
Низкое сцепление связано с двумя или несколькими модулями. Если изменение в одном модуле приводит к множеству изменений в другом модуле, то они, как говорят, сильно связаны. Именно здесь помогает интерфейсное программирование. Любое изменение в модуле не повлияет на другой модуль, так как интерфейс (среднее значение взаимодействия) между ними не изменился.
Высокая сплоченность. Положите похожие вещи вместе. Поэтому класс должен иметь метод или поведение для выполнения связанной работы. Просто чтобы дать преувеличенный плохой пример: реализация интерфейса List не должна иметь операции, связанные с String. Класс String должен иметь методы, поля, относящиеся к String, и аналогичным образом реализация List должна иметь соответствующие вещи.
Надеюсь, что это поможет.
Краткий и четкий ответ
Короче говоря, низкое сцепление, поскольку я понял, что компоненты могут быть заменены, не влияя на правильное функционирование системы. Basicaly модулирует вашу систему на функциональные компоненты, которые можно обновлять индивидуально, не нарушая работу системы.
У вас есть смартфон? Есть ли одно большое приложение или много маленьких? Отвечает ли одно приложение другому? Можете ли вы использовать одно приложение при установке, обновлении и/или удалении другого? То, что каждое приложение является самодостаточным, является высокой связностью. То, что каждое приложение не зависит от других, - это низкая связь. DevOps поддерживает эту архитектуру, потому что это означает, что вы можете выполнять дискретное непрерывное развертывание без нарушения целостности всей системы.
Низкое сцепление и высокая когезия являются рекомендуемым явлением.
Связывание означает, что различные модули взаимозависимы и как другие модули влияют на изменение некоторых/значительных функциональных возможностей модуля. Низкое сцепление подчеркивается, поскольку зависимость должна поддерживаться на низком уровне, так что к другим модулям будут внесены самые незначительные/незначительные изменения.
Пример может оказаться полезным. Представьте себе систему, которая генерирует данные и помещает их в хранилище данных, либо файл на диске, либо базу данных.
Высокое сцепление может быть достигнуто путем разделения кода хранилища данных из кода производства данных. (и фактически отделяет дисковое хранилище от хранилища базы данных).
Низкое сцепление может быть достигнуто путем обеспечения того, чтобы при производстве данных не было лишних знаний о хранилище данных (например, не запрашивает хранилище данных о именах файлов или соединениях db).
Наследование или обобщение является примером высокой связи (то есть высокой взаимозависимости). Под этим я подразумеваю, что в наследовании часто родительский класс определяет базовые функциональные возможности, которые используются его дочерним классом, и изменение методов родительского класса напрямую влияет на его дочерние классы. Следовательно, мы можем сказать, что между классами существует большая степень взаимозависимости.
Реализация или использование интерфейса является примером высокой когезии (то есть низкой взаимозависимости). Это означает, что интерфейс выдвигает контракт для любого класса, который его реализует, но каждый класс имеет право реализовывать методы, объявленные в интерфейсе по-своему, и изменения в методе, объявленном в одном классе, не влияют ни на какой другой класс.
Сплоченность - насколько тесно все связано друг с другом.
Муфта - как все связано друг с другом.
Давайте возьмем пример - мы хотим спроектировать автомобиль для самостоятельного вождения.
(1) Нам нужен мотор для правильной работы.
(2) Нам нужна машина, чтобы ехать самостоятельно.
Все классы и функции (1) запуска двигателя и его работы отлично работают вместе, но не помогают управлять автомобилем. Поэтому мы помещаем эти классы за контроллером двигателя.
Все классы и функции в (2) отлично работают, чтобы заставить автомобиль рулить, ускоряться и тормозить. Они не помогают машине заводиться или отправлять бензин на поршни. Поэтому мы размещаем эти классы за своим собственным контроллером вождения.
Эти контроллеры используются для связи со всеми доступными классами и функциями. Контроллеры тогда общаются только друг с другом. Это означает, что я не могу вызвать функцию в классе поршней из класса педалей газа, чтобы заставить машину двигаться быстрее.
Класс педалей должен попросить контроллер вождения поговорить с контроллером двигателя, который затем скажет поршневому классу двигаться быстрее. Это позволяет нам, программистам, находить проблемы и объединять большие программы, не беспокоясь. Это потому, что весь код работал за контроллером.
Вот ответ немного абстрактного теоретического графа:
Давайте упростим задачу, только посмотрев на (направленные) графы зависимостей между объектами с состоянием.
Чрезвычайно простой ответ можно проиллюстрировать, рассмотрев два предельных случая графов зависимостей:
1-й предельный случай: кластерные графы.
Граф кластеров является наиболее совершенной реализацией графа зависимостей с высокой когезией и низкой связью (с учетом набора размеров кластера).
Зависимость между кластерами максимальна (полностью связна), а межкластерная зависимость минимальна (ноль).
Это абстрактная иллюстрация ответа в одном из предельных случаев.
2-й предельный случай - это полностью связный граф, где все зависит от всего.
Реальность где-то посередине, чем ближе к кластерному графу, тем лучше, по моему скромному пониманию.
С другой точки зрения: при взгляде на ориентированный граф зависимостей в идеале он должен быть ациклическим, если нет, то циклы образуют наименьшие кластеры/компоненты.
Один шаг вверх/вниз по иерархии соответствует "одному случаю" слабой связи, тесной сплоченности в программном обеспечении, но этот принцип слабой связи/тесной сплоченности можно рассматривать как повторяющееся явление на разных глубинах ациклического ориентированного графа (или один из его связующего дерева).
Такое разложение системы на иерархию помогает преодолеть экспоненциальную сложность (скажем, в каждом кластере 10 элементов). Тогда на 6 слоях это уже 1 миллион объектов:
10 кластеров образуют 1 сверхскопление, 10 сверхскоплений образуют 1 сверхкластер и т.д.... без концепции тесной сплоченности, слабой связи такая иерархическая архитектура была бы невозможна.
Так что это может быть реальной важностью истории, а не только низкой связью с высокой когезией только в двух слоях. Реальная важность становится ясной при рассмотрении абстракций более высокого уровня и их взаимодействия.