В чем разница между сцеплением и сцеплением?
Как сцепление и когезия могут привести к хорошему или плохому дизайну программного обеспечения?
Каковы некоторые примеры, описывающие разницу между ними и их влияние на общее качество кода?
В чем разница между сцеплением и сцеплением?
Как сцепление и когезия могут привести к хорошему или плохому дизайну программного обеспечения?
Каковы некоторые примеры, описывающие разницу между ними и их влияние на общее качество кода?
Cohesion относится к тому, что может сделать класс (или модуль). Низкая сплоченность будет означать, что класс выполняет самые разнообразные действия - он широкий, не сфокусированный на том, что он должен делать. Высокая сплоченность означает, что класс ориентирован на то, что он должен делать, т.е. Только методы, относящиеся к намерению класса.
Пример низкой когезии:
-------------------
| Staff |
-------------------
| checkEmail() |
| sendEmail() |
| emailValidate() |
| PrintLetter() |
-------------------
Пример высокой степени сцепления:
----------------------------
| Staff |
----------------------------
| -salary |
| -emailAddr |
----------------------------
| setSalary(newSalary) |
| getSalary() |
| setEmailAddr(newEmail) |
| getEmailAddr() |
----------------------------
Что касается связи, это относится к тому, как близкие или зависимые два класса/модуля относятся друг к другу. Для классов с низкой связью изменение чего-то крупного в одном классе не должно влиять на другое. Высокое сцепление затруднит изменение и поддержание вашего кода; поскольку классы тесно связаны друг с другом, для внесения изменений может потребоваться полная модернизация системы.
Хороший дизайн программного обеспечения имеет высокий уровень сцепления и с низкой связью.
Высокая когезия внутри модулей и низкая связь между модулями часто рассматриваются как связанные с высоким качеством в языках программирования ОО.
Например, код внутри каждого Java-класса должен иметь высокую внутреннюю сплоченность, но быть как можно слабее связанным с кодом в других Java-классах.
Глава 3 из Meyer Object-Oriented Software Construction (2-е издание) является отличным описанием этих проблем.
Сплоченность является показателем отношений внутри модуля.
Связь является показателем взаимосвязей между модулями.
когезия
Связь
проверьте эту ссылку
Cohesion - это показатель того, как связаны и сфокусированы обязанности программного элемента.
Связь относится к тому, насколько сильно программный элемент связан с другими элементами.
Программным элементом может быть класс, пакет, компонент, подсистема или система. И при разработке систем рекомендуется иметь программные элементы с высокой связью и поддерживать Низкое соединение.
Низкая когезия приводит к монолитным классам, которые трудно поддерживать, понимать и уменьшать повторную атаку. Аналогично Высокая связь приводит к тесно связанным классам, и изменения, как правило, не являются нелокальными, трудно меняются и уменьшают повторное использование.
Мы можем принять гипотетический сценарий, в котором мы проектируем типичный монитор ConnectionPool
со следующими требованиями. Обратите внимание, что это может выглядеть слишком просто для простого класса, такого как ConnectionPool
, но основное намерение состоит в том, чтобы продемонстрировать низкую связь и высокую степень сцепления с некоторым простым примером, и я думаю должен помочь.
При низком сцеплении мы могли бы создать класс ConnectionPool
, принудительно наполнив все эти функции/обязанности одним классом, как показано ниже. Мы видим, что этот единственный класс отвечает за управление подключением, взаимодействие с базой данных, а также поддерживает статистику соединений.
С высокой связностью мы можем назначить эту ответственность по классам и сделать ее более удобной и многоразовой.
Чтобы продемонстрировать Низкое сцепление, мы продолжим диаграмму с высокой степенью сцепления ConnectionPool
выше. Если мы рассмотрим приведенную выше диаграмму, хотя она поддерживает высокую степень сцепления, ConnectionPool
тесно связан с классом ConnectionStatistics
и PersistentStore
, он напрямую взаимодействует с ними. Вместо этого, чтобы уменьшить связь, мы могли бы ввести интерфейс ConnectionListener
, и эти два класса реализуют интерфейс и позволяют им регистрироваться в классе ConnectionPool
. И ConnectionPool
будет перебирать эти прослушиватели и уведомлять их о событиях получения и выпуска соединения и позволяет уменьшить сцепление.
Примечание /Word или Внимание:. Для этого простого сценария это может выглядеть как излишний, но если мы представляем сценарий реального времени, когда нашему приложению необходимо взаимодействовать с несколькими сторонними службами для завершения транзакции: Непосредственное связывание нашего кода с услугами сторонних поставщиков означало бы, что любые изменения в сторонней службе могут привести к изменениям в нашем коде в нескольких местах, вместо этого мы могли бы иметь Facade
, который взаимодействует с этими несколькими службами внутри страны, и любые изменения в сервисы становятся локальными для Facade
и обеспечивают низкую связь с услугами третьей стороны.
Увеличение сцепления и снижение сцепления действительно ведут к хорошему дизайну программного обеспечения.
Cohesion разделяет вашу функциональность так, чтобы она была кратким и близким к соответствующим ей данным, в то время как развязка гарантирует, что функциональная реализация изолирована от остальной системы.
Развязка позволяет вам изменить реализацию, не затрагивая другие части вашего программного обеспечения.
Cohesion гарантирует, что реализация более специфична для функциональности и в то же время упрощается.
Наиболее эффективным методом уменьшения сцепления и увеличения сцепления является дизайн по интерфейсу.
Это основные функциональные объекты должны "знать" друг друга только через интерфейс (интерфейсы), который они реализуют. Реализация интерфейса вводит сплоченность как естественное следствие.
Несмотря на то, что в некоторых сценариях не реалистично, это должна быть цель дизайна для работы.
Пример (очень отрывочный):
public interface IStackoverFlowQuestion
void SetAnswered(IUserProfile user);
void VoteUp(IUserProfile user);
void VoteDown(IUserProfile user);
}
public class NormalQuestion implements IStackoverflowQuestion {
protected Integer vote_ = new Integer(0);
protected IUserProfile user_ = null;
protected IUserProfile answered_ = null;
public void VoteUp(IUserProfile user) {
vote_++;
// code to ... add to user profile
}
public void VoteDown(IUserProfile user) {
decrement and update profile
}
public SetAnswered(IUserProfile answer) {
answered_ = answer
// update u
}
}
public class CommunityWikiQuestion implements IStackoverflowQuestion {
public void VoteUp(IUserProfile user) { // do not update profile }
public void VoteDown(IUserProfile user) { // do not update profile }
public void SetAnswered(IUserProfile user) { // do not update profile }
}
В каком-либо другом месте вашей кодовой базы вы можете иметь модуль, который обрабатывает вопросы независимо от того, что они собой представляют:
public class OtherModuleProcessor {
public void Process(List<IStackoverflowQuestion> questions) {
... process each question.
}
}
лучшее объяснение Cohesion происходит от кода дяди Боба:
Классы должны иметь небольшое количество переменных экземпляра. Каждый из методов класса должен манипулировать одной или несколькими из этих переменных. В целом, чем больше переменных используется метод, тем более связным этот метод является его класс. Класс, в котором каждая переменная используется каждым методом, является максимально сплоченным.
В целом нецелесообразно и невозможно создать такие максимально сплоченные классы; с другой стороны, мы хотели бы, чтобы сплоченность была высокой. Когда когезия высока, это означает, что методы и переменные класса являются со-зависимыми и объединены вместе как логическое целое.
Стратегия сохранения функций, небольших и содержащих короткие списки параметров, может иногда приводить к распространению переменных экземпляра, которые используются подмножеством методов. Когда это происходит, это почти всегда означает, что есть хотя бы один другой класс, пытающийся выйти из более крупного класса. Вы должны попытаться разделить переменные и методы на два или более класса, чтобы новые классы были более сплоченными.
Cohesion в разработке программного обеспечения - это степень, в которой элементы определенного модуля принадлежат друг другу. Таким образом, это показатель того, насколько сильно связана каждая функциональность, выраженная исходным кодом программного модуля.
Связь в простых словах - это то, насколько один компонент (опять же, представьте, что класс, хотя и не обязательно) знает о внутренних действиях или внутренних элементах другого, то есть о том, сколько знаний у него есть другой компонент.
Я написал сообщение в блоге об этом, если вы хотите немного подробнее ознакомиться с примерами и рисунками. Я думаю, что он отвечает на большинство ваших вопросов.
просто, Cohesion представляет степень, в которой часть базы кода формирует логически единую атомарную единицу. Соединение, с другой стороны, представляет степень, в которой одна единица независима от других. Другими словами, это количество соединений между двумя или более устройствами. Чем меньше число, тем ниже муфта.
По сути, высокая сплоченность означает хранение частей базы кода, которые связаны друг с другом, в одном месте. Слабое связывание, в то же время, сводится к тому, чтобы максимально разделить несвязанные части кодовой базы.
Типы кода с точки зрения сплоченности и связи:
Идеальным является код, который следует руководящим принципам. Это слабосвязанный и очень сплоченный. Мы можем проиллюстрировать такой код этой картинкой:
Объект Бога является результатом введения высокой сплоченности и высокой связи. Это анти-шаблон и в основном означает один фрагмент кода, который выполняет всю работу одновременно: плохо выбирается, когда границы между различными классами или модулями выбраны плохо
Разрушительная развязка - самая интересная. Иногда это происходит, когда программист пытается настолько отделить кодовую базу, что код полностью теряет фокус:
читать больше здесь
Сплоченность (Co-hesion): Co, что означает вместе, hesion, что означает придерживаться. Система склеивания частиц разных веществ.
Для реального примера:
img Предоставлено
Целое больше, чем сумма частей -Aristotle.
Когезия является порядковым типом измерения и обычно описывается как "высокая когезия" или "низкая когезия". Модули с высокой когезией имеют тенденцию быть предпочтительными, поскольку высокая когезия связана с несколькими желательными характеристиками программного обеспечения, включая надежность, надежность, возможность повторного использования и понятность. Напротив, низкая когезия связана с нежелательными чертами, такими как трудность в обслуживании, тестировании, повторном использовании или даже понимании. вики
Сцепление обычно противопоставляется сплоченности. Низкая связь часто коррелирует с высокой когезией и наоборот. Низкая связь часто является признаком хорошо структурированной компьютерной системы и хорошего дизайна, а в сочетании с высокой связностью поддерживает общие цели высокой читабельности и удобства обслуживания. вики
сплоченность относится все о том, как разработан один класс. Сплоченность - это объектно-ориентированный принцип, наиболее тесно связанный с обеспечением того, чтобы класс был разработан с единственной, четко сфокусированной целью. Чем более сфокусирован класс, тем больше сплоченность этого класса. Преимущества высокой когезии состоят в том, что такие классы гораздо легче поддерживать (и реже менять), чем классы с низкой когезией. Еще одним преимуществом высокой сплоченности является то, что классы с четко определенной целью, как правило, более пригодны для повторного использования, чем другие классы.
На изображении выше мы видим, что при низкой когезии только один класс отвечает за выполнение множества не общих задач, что снижает вероятность повторного использования и обслуживания. Но в высокой степени сплоченности существует отдельный класс для всех заданий, выполняющих определенное задание, что повышает удобство использования и обслуживания.
Я думаю, что различия могут быть поставлены следующим образом:
В этом сообщении в блоге я пишу об этом более подробно.
Cohesion является показателем относительной функциональной силы модуля.
Совместное представление:
"целеустремленность" модуля
OO view:
cohesion подразумевает, что компонент или класс инкапсулирует только атрибуты и операции, которые тесно связаны друг с другом и самим классом или компонентом
Levels cohesion
Functional
Layer
Communicational
Sequential
Procedural
Temporal
utility
Связь является показателем относительной взаимозависимости между модулями.
Связь зависит от сложности интерфейса между модулями, точка, в которой ввод или ссылка делается на модуль, и какие данные пройти через интерфейс.
Обычный вид: Степень, с которой компонент подключен к другим компонентам и внешнему миру.
OO view: качественная мера степени, с которой классы связаны друг с другом
Уровень сцепления
Content
Common
Control
Stamp
Datap >
Возвратный вызов
Тип использования
Включение или импорт
External #
Связь= взаимодействие/взаимосвязь между двумя модулями... Cohesion= взаимодействие между двумя элементами внутри модуля.
Программное обеспечение состоит из множества модулей. Модуль состоит из элементов. Рассмотрим модуль - это программа. Функция внутри программы - это элемент.
Во время выполнения вывод программы используется как вход для другой программы. Это называется взаимодействием модуля или процесса для обработки связи. Это также называется связью.
В рамках одной программы вывод функции передается другой функции. Это называется взаимодействием элементов внутри модуля. Это также называется сплоченностью.
Пример:
Связь= связь между двумя разными семействами... Сплоченность= общение между отцом и матерью в семье.
Мы хотим, чтобы связанное поведение сидели вместе и не связанное с ним поведение, чтобы сидеть где-то в другом месте. Зачем? Ну, если мы хотим изменить поведение, мы хотим изменить его в одном месте и как можно скорее отпустить это изменение. Если мы должны изменить это поведение в самых разных местах, вам нужно будет выпустить множество разных сервисов (возможно, в то же время), чтобы выполнить это изменение. Вносить изменения в множество разных мест происходит медленнее, и развертывание множества услуг одновременно является рискованным - и того, чего мы хотим избежать. Поэтому мы хотим найти границы внутри нашей проблемной области, которые помогут обеспечить, чтобы связанное поведение находилось в одном месте. - сплоченность
и которые общаются с другими границами как можно более свободно. - связь
Проще говоря, сплоченность означает, что класс должен представлять единую концепцию.
Открытый интерфейс класса является связным, если все функции класса связаны с концепцией, которую представляет класс. Например, вместо того, чтобы иметь класс CashRegister, наличие сплоченности функций CashRegister и Coin делит его на 2 класса - класс CashRegister и Coin.
При связывании один класс зависит от другого, поскольку использует объекты этого класса.
Проблема с высокой связью в том, что она может создавать побочные эффекты. Одно изменение в одном классе может вызвать неожиданную ошибку в другом классе и может привести к поломке всего кода.
Как правило, высокая когезия и низкая связь считается высоким качеством ООП.
Термин сплоченность действительно немного противоречит тому, что он означает в разработке программного обеспечения.
Общим смыслом сплоченности является то, что что-то, что хорошо слипается, объединяется и характеризуется сильной связью, такой как молекулярное притяжение. Однако в разработке программного обеспечения это означает стремление к классу, который в идеале делает только одно, поэтому несколько подмодулей даже не задействованы.
Возможно, мы можем думать об этом таким образом. Часть имеет наибольшую сплоченность, когда она единственная (выполняет только одну функцию и не может быть разбита дальше). Это то, что желательно в разработке программного обеспечения. Сплоченность - это просто другое название "единой ответственности" или "разделения интересов".
Термин " связывание" на руке достаточно интуитивен, что означает, что когда модуль не зависит от слишком большого количества других модулей, и те, с которыми он соединяется, могут быть легко заменены, например, следуя принципу подстановки Лискова.
В общем, сплоченность - это то, где все методы в классе звучат одинаково и часто перегружены. например:
MyClass {
displayCar();
displayCarMinimized();
displayCarSpecialised();
display(Vehicle v)
display(Vehicle v, Country c)
displayAll()
}