У меня проблемы с пониманием утверждения low in coupling and high in cohesion. Я много гуглил и читал об этом, но мне все еще трудно понять.
Насколько я понимаю, High cohesion означает, что у нас должны быть классы, специализированные для выполнения определенной функции. Надеюсь, это правильно? Как класс проверки кредитных карт, который специализируется только на проверке кредитных карт.
И до сих пор не понимаете, что такое low Coupling?
Во что я верю:
Сплоченность относится к степени, в которой элементы модуля / класса принадлежат друг другу, предполагается, что связанный код должен быть близко друг к другу, поэтому мы должны стремиться к высокой сплоченности и связывать весь связанный код как можно ближе. Это связано с элементами внутри модуля / класса.
Связывание относится к степени, в которой различные модули / классы зависят друг от друга. Предполагается, что все модули должны быть, насколько это возможно, независимыми, поэтому связь низкая. Это связано с элементами среди различных модулей / классов.
Для визуализации всей картины пригодятся:
Снимок экрана был взят с сайта Coursera < / а>.
Сплоченность в разработке программного обеспечения, как и в реальной жизни, - это то, насколько элементы, составляющие единое целое (в нашем случае, скажем, класс), можно сказать, что они действительно принадлежат друг другу. Таким образом, это мера того, насколько сильно связана каждая часть функциональности, выраженная исходным кодом программного модуля.
Один из способов взглянуть на сплоченность с точки зрения объектно-ориентированного подхода - использовать в методах класса какие-либо частные атрибуты.
Сейчас обсуждение шире, чем это, но Высокая сплоченность (или лучший тип сплоченности - функциональная сплоченность) - это когда части модуля сгруппированы, потому что все они вносят свой вклад в одну четко определенную задачу модуля. .
Связывание простыми словами - это то, насколько один компонент (опять же, представьте себе класс, хотя и не обязательно) знает о внутренней работе или внутренних элементах другого, т. е. сколько он знает о другом компоненте. .
Слабая связь - это метод соединения компонентов в системе или сети таким образом, чтобы эти компоненты зависели друг от друга в наименьшей практически возможной степени ...
Я написал об этом сообщение в блоге. В нем подробно обсуждается все это с примерами и т. Д. В нем также объясняются преимущества того, почему вы должны следовать этим принципам.
В разработке программного обеспечения высокая сплоченность означает, что класс должен хорошо выполнять одно и то же. Высокая сплоченность тесно связана с принципом единой ответственности.
Низкая связь предполагает, что класс должен иметь как можно меньше зависимостей. Кроме того, зависимости, которые должны существовать, должны быть слабыми зависимостями - предпочитать зависимость от интерфейса, а не от конкретного класса, или предпочитать композицию наследованию.
Высокая когезия и низкая взаимосвязь дают нам лучше разработанный код, который легче поддерживать.
Краткий и четкий ответ
Низкая связь возникает в контексте двух или многих модулей. Если изменение в одном модуле приводит к множеству изменений в другом модуле, то они считаются сильно связанными. Здесь помогает программирование на основе интерфейса. Любое изменение внутри модуля не повлияет на другой модуль, поскольку интерфейс (способ взаимодействия) между ними не изменился.
Высокая сплоченность - соедините похожие вещи. Итак, у класса должен быть метод или поведение для выполнения связанной работы. Просто чтобы привести преувеличенный плохой пример: реализация интерфейса List не должна иметь операции, связанные со String. Класс String должен иметь методы, поля, которые актуальны для String, и аналогично реализация List должна иметь соответствующие вещи.
Надеюсь, это поможет.
Короче говоря, низкая связь, как я понял, означала, что компоненты можно менять, не влияя на правильное функционирование системы. По сути, модулируйте вашу систему на функционирующие компоненты, которые можно обновлять индивидуально, не нарушая работу системы.
Сплоченность - насколько все взаимосвязано друг с другом.
Связь - как все связано друг с другом.
Возьмем пример - мы хотим спроектировать беспилотный автомобиль.
(1) Нам нужно, чтобы мотор работал правильно.
(2) Нам нужно, чтобы машина двигалась сама по себе.
Все классы и функции в (1) запуск двигателя и обеспечение его работы отлично работают вместе, но не помогают машине управлять. Поэтому мы помещаем эти классы за Engine Controller.
Все классы и функции в (2) отлично работают, чтобы заставить машину управлять, ускоряться и тормозить. Они не запускают машину и не направляют бензин к поршням. Поэтому мы размещаем эти классы за собственным Driving Controller.
Эти контроллеры используются для связи со всеми доступными классами и функциями. Тогда контроллеры общаются только друг с другом. Это означает, что я не могу вызвать функцию в классе поршня из класса педали газа, чтобы заставить машину двигаться быстрее.
Класс педали должен попросить контроллер движения поговорить с контроллером двигателя, который затем скажет классу поршня двигаться быстрее. Это позволяет нам, программистам, находить проблемы и позволяет нам, не беспокоясь, комбинировать большие программы. Это потому, что весь код работал за контроллером.
У тебя есть смартфон? Есть одно большое приложение или много маленьких? Одно приложение отвечает другому? Можете ли вы использовать одно приложение при установке, обновлении и / или удалении другого? То, что каждое приложение является автономным, является высокой связностью. То, что каждое приложение не зависит от других, является слабой связью. DevOps отдает предпочтение этой архитектуре, потому что это означает, что вы можете выполнять дискретное непрерывное развертывание, не нарушая работу всей системы.
Наследование или обобщение - это пример сильной связи (т.е. высокой взаимозависимости). Я имел в виду, что при наследовании родительский класс часто определяет базовые функции, которые используются его дочерним классом, и изменение методов родительского класса напрямую влияет на его дочерние классы. Следовательно, мы можем сказать, что существует большая степень взаимозависимости между классами.
Реализация или использование интерфейса является примером высокой сплоченности (то есть низкой взаимозависимости). Это означает, что интерфейс выдвигает контракт для любого класса, который его реализует, но каждый класс имеет право реализовывать методы, объявленные в интерфейсе, по-своему, и изменения в методе, объявленном в одном классе, не влияют на другие классы.
Низкое сцепление и высокая когезия - рекомендуемые явления.
Связь означает, в какой степени различные модули взаимозависимы и как другие модули влияют на изменение некоторых / значительных функциональных возможностей модуля. Подчеркивается низкая взаимосвязь, поскольку зависимость должна поддерживаться на низком уровне, чтобы в другие модули вносились минимальные / незначительные изменения.
Пример может быть полезным. Представьте себе систему, которая генерирует данные и помещает их в хранилище данных, будь то файл на диске или база данных.
Высокая согласованность может быть достигнута путем отделения кода хранилища данных от кода производства данных. (и фактически отделяет дисковое хранилище от хранилища базы данных).
Низкой связи можно добиться, убедившись, что производство данных не имеет ненужных знаний о хранилище данных (например, не запрашивает хранилище данных об именах файлов или подключениях к базе данных).
Вот ответ немного абстрактно, с теоретической точки зрения:
Давайте упростим проблему, посмотрев только на (направленные) графы зависимостей между объектами с состоянием.
Чрезвычайно простой ответ можно проиллюстрировать, рассмотрев два предельных случаев графов зависимостей. :
Первый предельный случай: кластерные графы.
Кластерный граф - это наиболее совершенная реализация графа зависимостей с высокой степенью связанности и низкой связанностью (при заданном наборе размеров кластера).
Зависимость между кластерами максимальная (полносвязная), а межкластерная зависимость минимальная (нулевая).
Это абстрактная иллюстрация ответа в одном из ограничивающих случаев.
2-й предельный случай - это полносвязный граф, где все зависит от всего.
Реальность находится где-то посередине, в моем скромном понимании, чем ближе к графу кластеров, тем лучше.
С другой точки зрения: если смотреть на направленный граф зависимостей, в идеале он должен быть ациклическим, если нет, то циклы образуют самые маленькие кластеры / компоненты.
Один шаг вверх / вниз по иерархии соответствует «одному экземпляру» слабой связи, сильной связности в программном обеспечении, но можно рассматривать этот принцип слабой / сильной связи как повторяющееся явление на разных глубинах ациклического ориентированного графа (или на одно из его остовных деревьев).
Такое разложение системы на иерархию помогает преодолеть экспоненциальную сложность (скажем, каждый кластер состоит из 10 элементов). Тогда на 6 слоях это уже 1 миллион объектов:
10 кластеров образуют 1 сверхскопление, 10 сверхскоплений образуют 1 гиперкластер и так далее ... без концепции тесной связи, слабой связи такая иерархическая архитектура была бы невозможна.
Так что это может быть реальная важность истории, а не просто высокая когезия и низкая связь только в двух слоях. Настоящая важность становится очевидной при рассмотрении абстракций более высокого уровня и их взаимодействий.
Я думаю, что у вас так много определений, но в случае, если у вас все еще есть сомнения или если вы новичок в программировании и хотите углубиться в это, я предлагаю вам посмотреть это видео, https://youtu.be/HpJTGW9AwX0 Это просто ссылка для получения дополнительной информации о полиморфизме ... Надеюсь, вы лучше поймете это
Низкое сцепление: - Будет очень просто. Если вы измените свой модуль, как это повлияет на другие модули.
Пример: - Если ваш сервисный API представлен как JAR, любое изменение сигнатуры метода нарушит вызывающий API (высокая / жесткая связь).
Если ваш модуль и другой модуль обмениваются данными через асинхронные сообщения. Пока вы получаете сообщения, ваша подпись изменения метода будет локальной для вашего модуля (низкая связь).
Вне курса, если есть изменение в формате сообщения, вызывающий клиент должен будет внести некоторые изменения.
Возьмем, к примеру, старую материнскую плату ПК.
Это означало, что конкретный порт предназначался только для определенного устройства и ни для кого другого.
Это сильное / высокое сцепление.
Поскольку мышь используется только для управления курсором и соответствующими функциями, клавиатура для набора клавиш и т. Д., Т.е. они выполняют только ту задачу, для которой предназначены, это Высокая сплоченность.
Если у мыши было несколько кнопок 'a' 'b' 'c' для ввода, значит, она делает больше, чем должна, поскольку клавиатура уже выполняет их, это Низкое сцепление
К счастью, устаревшее использование эксклюзивных портов было заменено стандартным (интерфейсом), который мы называем USB. Это Слабое / слабое сцепление.
Глядя на эти физические атрибуты, кажется очевидным, что так оно и должно быть, но при написании программного обеспечения очень легко потерять из виду, какие функции должны быть размещены, где и т. Д. И, следовательно, в качестве напоминания во всем, что жизни, всегда придерживайтесь:
"Высокая сплоченность и слабая связь"
