Как я могу определить, сильно ли связано программное обеспечение?

Я знаком с термином «сильно связанные», но мне любопытно, есть ли признаки (запахи кода), которые могут указывать на то, что код тесно связан. В настоящее время я работаю с Java EE, но это может относиться к любому языку.

Редактировать:

Если кому-то интересно, эта статья звучит полезно: в поисках качества кода: остерегайтесь парней! (IBM)

На мой взгляд, индикатор номер один плохо связанных модулей - это двусторонние зависимости. Например, Module1 one вызывает некоторую функцию в Module2, а Module2 вызывает некоторую функцию в Module1.

Большинство интерфейсов должны быть однонаправленными. Если вызываемому модулю необходимо передать вызывающему модулю некоторую информацию, которая не возвращается как часть вызова, он должен использовать какой-либо механизм передачи сообщений или механизм запуска событий, такой как очередь сообщений. В идеале дескриптор интерфейса передачи сообщений должен передаваться во время некоторой инициализации или процесса регистрации. Это полностью абстрагирует интерфейс таким образом, что модулю на самом деле все равно, для кого это событие ... следовательно, он не связан.

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

Третий инструмент, так сказать, это спросить себя: «Могу ли я вынуть этот модуль и заменить его, не требуя изменений других модулей.

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

Старая поговорка гласит: «Ты можешь коснуться своих друзей, и ты можешь коснуться своих рядовых. Но ты не можешь коснуться рядовых своих друзей». Это соединение в двух словах.

Признаки сильно связанного кода включают в себя очень большие интерфейсы, которые позволяют людям узнать о частных деталях реализации, и объекты, которые, кажется, «много знают друг о друге». Существуют инструменты для автоматического анализа, которые помечают код, который выглядит для вас тесно связанным. См. Http://www.scitools.com/features/metricsintro.php для случайного. (Я понятия не имею, насколько хорошо это работает. Просто он оказался довольно высоким в поиске Google.)

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

Это также одно из лучших лекарств, но вы должны делать это во время кодирования (например, TDD), чтобы сохранять честность.

Для меня очевидным признаком является то, что все является публичным.

Другим признаком является нарушение закона Деметры - чрезмерные ссылки this.SomeObj.SomeProp.SomeProp на нерегулярных интерфейсах.

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

Когда он извлекал данные из созданных им элементов управления, он делал это так:

var control = activeDataEntryControl as CustomTextBox;
if (control != null)
   result = control.NestedTextBox.Text;

/* several other controls */

Эффект ряби .

Каждое изменение имеет волновой эффект во всех тесно связанных модулях.

Принцип «Открыто-Закрыто» был нарушен в связи с тем, что он не закрыт надлежащим образом и утечка изменений.

Проверьте количество # include / import и т. Д. Между классами / packages / dlls / jars / whatnots. Попробуйте нарисовать график этого, мысленно, вручную или с помощью какого-либо инструмента.

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

Если вы обнаружите, что реализовать функцию невозможно, так как не знаете, в чем заключается конкретная ответственность, значит, ваша система слишком тесно связана.

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

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

Я полагаю, что другой разумный метод измерения - это подсчет строк на диаграмме UML. Если у вас есть N объектов и N ^ N (или более) строк между ними, то ваш код в значительной степени максимально связан. N строк, вероятно, будет минимальным, как вы могли бы получить.