оптимизация высокой когезии и слабой связи - PullRequest
0 голосов
/ 09 сентября 2018

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

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

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

Буду признателен, если кто-нибудь поможет мне.

Ответы [ 3 ]

0 голосов
/ 09 сентября 2018

Я не был знаком с понятием сплоченности до того, как прочитал ваш вопрос. Из Википедии ( здесь ):

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

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

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

0 голосов
/ 09 сентября 2018

Я хочу начать отвечать, сказав, что это совершенно противоположно тому, что вы сказали как «два определения противоречивы».Я собираюсь описать, приведя цитату из системного анализа и проектирования Джона В. Сатцингера в меняющемся мире, ключевые факты книга

Низкая связь часто коррелирует с высокой связностью, инаоборот


Сказав в Монолитном , они просили вас спросить о ТВЕРДЫХ принципалах , что, если вы их примените, вы получитеПроект высокой когезии и слабой связи.

Вот определения:

1. Принцип единой ответственности (SRP)

Определение: Там должно бытьне более одной причины для изменения класса.

Преимущества:

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

2.Принцип открытого-закрытого (OCP)

Определение: Программные объекты (классы, модули, функции и т. Д.) Должны быть открыты для расширения, но закрыты для модификации.

Преимущества:

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

3.Принцип подстановки Лискова (LSP)

Определение: Объекты в программе должны заменяться экземплярами их подтипов без изменения правильности этой программы.

Преимущества:

  • слабая связь
  • Код более пригоден для повторного использования.
  • Иерархии классов легко понять.

4,Принцип сегрегации интерфейса (ISP)

Определение: многие клиентские интерфейсы лучше, чем один универсальный интерфейс

Преимущества:

  • Отделенная система.
  • Код, легко реорганизованный.

5.Принцип обращения зависимостей (DIP)

Определение: Модули высокого уровня не должны зависеть от модулей низкого уровня, скорее оба должны зависеть от абстракции.Абстракция не должна зависеть от деталей;довольно детализация должна зависеть от абстракции.

Преимущества:

  • высокая когезия.
  • уменьшить муфту.
  • кодмногоразовое использование.

Дополнительная информация


Книги

  • Полный код Стива Макконнелла
  • Чистый код дяди Боба
0 голосов
/ 09 сентября 2018

Согласно Википедии (https://en.wikipedia.org/wiki/Cohesion_(computer_science))

Высокая когезия часто коррелирует со слабой связью, и наоборот

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

...