оптимизация высокой когезии и слабой связанности

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

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

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

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


java oop loose-coupling cohesion
person Ali K. Nouri    schedule 09.09.2018    source источник
comment
Возможный дубликат Что означает "низкая связанность и высокая "сплоченность" означает   -  person Oleksandr Pyrohov    schedule 09.09.2018
comment
Спасибо за ваш комментарий. Предоставленная вами ссылка полностью отвечает на первую часть моего вопроса, однако она не показывает, существует ли общий подход к поддержанию слабой связи и высокой согласованности или это зависит от случая.   -  person Ali K. Nouri    schedule 10.09.2018

Ответы (3)


arrow_upward
9
arrow_downward

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

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

Сказав в Монолитике, они сигнализируют вам, чтобы вы спросили о принципах SOLID, что если вы их примените, это приведет к проекту высокой сплоченности и слабой связи.

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

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

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

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

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

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

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

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

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

3. Принцип замещения Лискова (LSP)

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

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

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

4. Принцип разделения интерфейсов (ISP)

Определение: множество клиентских интерфейсов лучше, чем один интерфейс общего назначения.

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

  • Развязанная система.
  • Код легко рефакторить.

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

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

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

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

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

Книги

  • Код Стива МакКоннелла завершен
  • Чистый код дяди Боба
person Community    schedule 09.09.2018
comment
Спасибо за развернутый ответ, очень помогает. Чтобы уточнить, говоря, что эти две цели противоречат друг другу, я имел в виду, что достижение проекта с очень связным и слабо связанным дизайном является проблемой противоречивых целей, а это означает, что если достигается максимальная согласованность, связь также будет максимальной, и наоборот. Поэтому наша цель — сбалансировать их должным образом. Мой вопрос в том, есть ли способ сделать это. Кроме того, существуют ли какие-либо критерии для поддержания этого баланса между сплоченностью и сцеплением? Или только соблюдение принципов SOLID гарантирует это? Спасибо за ваше время Мохаммад Реза. - person Ali K. Nouri; 10.09.2018
comment
не существует реального метода измерения этого баланса, но применение этих принципов гарантирует, что ваша система построена с высокой степенью связности и слабой связанности. есть также много других принципов, упомянутых в книгах, на которые я ссылался, но главные 5 - это ТВЕРДЫЕ принципы. - person MohammadReza Alagheband; 10.09.2018

arrow_upward
2
arrow_downward

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

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

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

person Ivan    schedule 09.09.2018

arrow_upward
2
arrow_downward

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

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

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

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

person Dici    schedule 09.09.2018
comment
Спасибо за Ваш ответ. Это информативно. Мне все еще интересно, существует ли какой-либо набор правил для достижения оптимального баланса между сплоченностью и согласованностью. Или, как прокомментировал @MohammadReza, для этого нет панацеи? - person Ali K. Nouri; 11.09.2018
comment
Я не уверен, я не применяю много теории в своем стиле кодирования, или, по крайней мере, не сознательно. Для меня это скорее вопрос чувства, чувства порядка и последовательности, но я недостаточно рационализирую это, чтобы иметь твердое мнение по таким темам, как сплоченность или взаимосвязь :p - person Dici; 12.09.2018