Як я можу визначити, чи програмне забезпечення є сильно пов'язаним?

Мені знайомий термін "сильно пов'язаний", але мені цікаво, якщо є ознаки (запахи коду), які можуть вказувати на те, що код сильно пов'язаний. Зараз я працюю з Java EE, але це стосується будь-якої мови.

Редагувати:

У разі, коли когось цікавить, ця стаття звучить корисно: Домагаючись якості коду: Остерігайтеся тісної пари! (IBM)

Показником номер один погано поєднаних модулів, на мою думку, є двосторонні залежності. Наприклад, Module1 one викликає деяку функцію в Module2, а Module2 викликає деяку функцію в Module1.

Більшість інтерфейсів повинні бути односпрямованими. Якщо викликаний модуль повинен передати деяку інформацію модулю виклику, який не повертається як частина виклику, він повинен використовувати якийсь механізм передачі повідомлення або механізм ініціювання події, такий як черга повідомлень. В ідеалі інтерфейс обробки та передачі повідомлень повинен передаватися під час ініціалізації чи реєстрації. Це повністю абстрагує інтерфейс таким чином, що модуль насправді не хвилює, для кого подія ... отже, він роз'єднується.

Ще одна вказівка ​​- коли один модуль постійно викликає якийсь інший модуль для певного набору даних. Це повинно змусити вас запитати, хто насправді повинен володіти набором даних. Чому саме цьому модулю, про який йдеться, завжди потрібно бачити дані, що належать до якогось іншого модуля?

Третій інструмент, так би мовити, - запитати себе: "Чи можу я витягнути цей модуль і замінити його, не вимагаючи змін до інших модулів.

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

Стара конструкція говорить: "Ви можете доторкнутися до своїх друзів, і ви можете доторкнутися до своїх приватних осіб. Але ви не можете чіпати своїх друзів приватних осіб". Це зчеплення в двох словах.

Ознаки сильно зв'язаного коду включають дуже великі інтерфейси, які повідомляють людям про приватні деталі реалізації та об'єкти, які, здається, "багато знають один про одного". Існують інструменти для автоматичного аналізу, які позначать код, який виглядає для вас щільно. Дивіться http://www.scitools.com/features/metricsintro.php для випадкового. (Я не маю уявлення про те, наскільки добре це працює. Він просто виявився досить високим у пошуку Google.)

Спробуйте написати кілька тестів для занять. Якщо ви не можете легко перевірити заняття без необхідності створювати / знущатися з навантажень класів підтримки або будь-якого db / ui, то це впевнений ознака поганих зв’язків / залежностей.

Це також одне з найкращих ліків, але ви повинні робити це під час кодування (як TDD), щоб бути чесними.

Очевидною ознакою для мене є те, що все публічно.

Інша ознака - порушення закону Деметра - надмірна this.SomeObj.SomeProp.SomeProp посилання на невільні інтерфейси.

Я колись бачив, що я з тих пір отримав назву "клас лялькових майстрів", який створив форму введення даних на ходу. У нього було кілька інших порушень в розробці програмного забезпечення, тому найменша стурбованість викликала надмірне з'єднання.

Під час отримання даних із створених елементів керування це робилося так:

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

/* several other controls */

Мультиплікаційний ефект .

Кожна зміна має ефект пульсації через усі щільно з'єднані модулі.

Принцип "Відкрито-закрито" був порушений тим, що він не є належним чином закритим і змінюють витоки.

Перевірте кількість # включити / імпортувати тощо між класами / пакетами / dlls / jar / whatnots. Спробуйте намалювати графік цього, подумки, вручну або використовуючи якийсь інструмент.

• Якщо цей графік щільний (тобто багато з'єднань всюди), то ваша система монолітна і сильно пов'язана.
• Якщо він чітко розділений на шари, без з'єднань через / коритові шари, а з'єднань небагато, у вас є модульна і роз'єднана система.

Якщо ви вважаєте, що неможливо реалізувати функцію, оскільки ви не маєте уявлення, куди йде конкретна відповідальність, то ваша система занадто щільно пов'язана.

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

Практично всі запахи коду певним чином вказують на зайве з'єднання. Я гадаю, запах, який би найбільше вказував на сполучення, хоча міг би бути "Невідповідна інтимність" (мій улюблений запах).

Я вважаю, що іншим розумним методом для вимірювання буде підрахунок рядків у вашій UML-діаграмі. Якщо у вас N об'єктів і N ^ N (або більше) рядків між ними, ваш код майже максимально поєднаний. N рядків, ймовірно, буде приблизно таким же мінімальним, як ви могли отримати.