Что означает «низкий уровень сцепления и высокий уровень сцепления»

У меня проблемы с пониманием заявления low in coupling and high in cohesion. Я гуглил и много читал об этом, но все еще не могу понять.

Я понимаю High cohesion, что это означает, что у нас должны быть классы, специализированные для выполнения определенной функции. Надеюсь, это правильно? Как класс проверки кредитной карты, который специализируется только на проверке кредитных карт.

И все еще не понимаете, что означает низкое сцепление?

Я верю в это:

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

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

Для визуализации всей картины будет полезно:

Скриншот был взят из Coursera .

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

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

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

Связывание простыми словами - это то, сколько один компонент (опять же, представьте себе класс, хотя и не обязательно) знает о внутренней работе или внутренних элементах другого, т. Е. Сколько он знает о другом компоненте.

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

Я написал в блоге об этом. В нем все подробно обсуждается, с примерами и т. Д. Также объясняются преимущества того, почему вы должны следовать этим принципам.

В разработке программного обеспечения высокая сплоченность означает, что класс должен хорошо выполнять одно и одно. Высокая сплоченность тесно связана с принципом единой ответственности .

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

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

Краткий и четкий ответ

• Высокая сплоченность : элементы в одном классе / модуле должны функционально объединяться и выполнять одну конкретную вещь.
• Слабая связь : между различными классами / модулями должна быть минимальная зависимость.

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

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

Надеюсь, это поможет.

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

У тебя есть смартфон? Есть одно большое приложение или много маленьких? Одно приложение отвечает другому? Можно ли использовать одно приложение при установке, обновлении и / или удалении другого? То, что каждое приложение является автономным, является высокой сплоченностью. То, что каждое приложение не зависит от других, является слабой связью. DevOps предпочитает эту архитектуру, потому что это означает, что вы можете выполнять дискретное непрерывное развертывание, не нарушая целостность системы.

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

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

Сплоченность - насколько тесно все связано друг с другом.
Муфта - как все связано друг с другом.

Давайте рассмотрим пример - мы хотим спроектировать автомобиль для самостоятельного вождения.

(1) Нам нужен мотор для правильной работы.

(2) Нам нужна машина, чтобы ехать самостоятельно.

Все классы и функции (1) запуска двигателя и его работы прекрасно работают вместе, но не помогают управлять автомобилем. Поэтому мы помещаем эти классы за контроллером двигателя.

Все классы и функции в (2) отлично работают, чтобы заставить автомобиль рулить, ускоряться и тормозить. Они не помогают машине заводиться или отправлять бензин на поршни. Таким образом, мы размещаем эти классы за собственным контроллером вождения.

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

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

Низкое сцепление и высокая когезия - рекомендуемое явление.

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

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

Высокая когезия может быть достигнута путем отделения кода хранилища данных от кода производства данных. (и фактически отделяет дисковое хранилище от хранилища базы данных).

Низкая связь может быть достигнута, убедившись, что для производства данных нет ненужных знаний о хранилище данных (например, не спрашивает хранилище данных о именах файлов или соединениях БД).

Вот ответ немного абстрактного теоретического графа:

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

Чрезвычайно простой ответ можно проиллюстрировать, рассмотрев два предельных случая графов зависимостей:

1-й предельный случай : кластерные графы .

Граф кластеров является наиболее совершенной реализацией графа зависимостей с высокой когезией и низкой связью (с учетом набора размеров кластера).

Зависимость между кластерами максимальна (полностью связна), а межкластерная зависимость минимальна (ноль).

Это абстрактная иллюстрация ответа в одном из предельных случаев .

2-й предельный случай - это полностью связный граф, где все зависит от всего.

Реальность где-то посередине, чем ближе к кластерному графу, тем лучше, по моему скромному пониманию.

С другой точки зрения : при взгляде на ориентированный граф зависимостей в идеале он должен быть ациклическим, если нет, то циклы образуют наименьшие кластеры / компоненты.

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

Такое разложение системы на иерархию помогает преодолеть экспоненциальную сложность (скажем, в каждом кластере 10 элементов). Тогда на 6 слоях это уже 1 миллион объектов:

10 кластеров образуют 1 сверхскопление, 10 сверхскоплений образуют 1 сверхкластер и т. Д. ... без концепции тесной сплоченности, слабой связи такая иерархическая архитектура была бы невозможна.

Таким образом, это может быть реальной важностью истории, а не только низкой связью высокой когезии только в двух слоях. Реальная важность становится ясной при рассмотрении абстракций более высокого уровня и их взаимодействия.

Я думаю, что у вас есть слишком много определений, но если у вас все еще есть сомнения или если вы новичок в программировании и хотите углубиться в это, я предлагаю вам посмотреть это видео, https://youtu.be/HpJTGW9AwX0 Это просто ссылка, чтобы получить больше информации о полиморфизме ... Надеюсь, вы получите лучшее понимание с этим

Низкая связь: - Будет очень просто. Если вы измените свой модуль, как это повлияет на другие модули.

Пример: - Если ваш сервисный API представлен как JAR, любое изменение сигнатуры метода нарушит вызов API (High / Tight связывание).

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

Конечно, если есть изменения в формате сообщения, вызывающий клиент должен будет внести некоторые изменения.