Перейти до вмісту

Пов'язаність (програмування)

Матеріал з Вікіпедії — вільної енциклопедії.

Пов'язаність (згуртованість?) (англ. cohesion) в програмуванні - це міра того наскільки пов’язаним є код в одному модулі програми (наприклад через спільну семантику). Методи оцінки пов'язаності варіюються від якісних оцінок тексту програми з використанням рубрик з герменевтичним підходом до кількісних вимірювань міри пов'язаності коду програми. Пов'язаність - ординальна величина, і зазвичай в розмові виражається як "висока пов'язаність" чи "низька пов'язаність". Модулям з високою пов'язаністю віддається перевага, тому що висока пов'язаність асоціюється з кількома бажаними рисами програмного забезпечення, включаючи відмовостійкість, надійність, здатність до повторного використання, та зрозумілість, в той час, як низька пов'язаність асоціюється з небажаними рисами, такими як складність підтримки, тестування, повторного використання та розуміння.

Пов'язаність часто протиставляється зв'язності - іншому поняттю, однак висока пов'язаність часто корелює з слабкою зв'язністю. Метрики програмного забезпечення такі як пов'язаність та зв'язність винайдені Ларрі Констянтином[1] і базуються на характеристиках "добрих" практик програмування, які зменшують витрати на модифікацію та підтримку.

Слабка пов'язаність

[ред. | ред. код]

В ООП, якщо методи деякого класу як правило подібні в багатьох аспектах, то клас вважається таким що має високу пов'язаність.

Пов'язаність зменшується якщо:

  • Функціонал вбудований в методи класу має мало спільного.
  • Методи виконують багато різних функцій, часто над грубо гранулярними чи непов'язаними наборами даних.

Недоліками низької (слабкої) пов'язаності є:

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

Типи пов'язаності

[ред. | ред. код]

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

Випадкова пов'язаність (найгірша)
Випадкова пов'язаність виникає тоді, коли частини модуля додаються в нього довільним чином; єдиним що їх пов'язує є те, що вони входять до одного модуля (наприклад клас "Utilities").
Логічна пов'язаність
частини модуля групуються разом тому що вони за логікою виконують одну функцію, навіть якщо вони різні за природою. Наприклад групування всіх підпрограм обробки вводу з клавіатури і миші.
Темпоральна пов'язаність
частини модуля групуються залежно від того в який момент часу виникає необхідність їх застосування. Наприклад функції що викликаються після виявлення помилки, які закривають відкриті файли, записують помилку в журнал, і повідомляють користувача.
Процедурна пов'язаність
частини модуля групуються тому що вони всі дотримуються певної послідовності дій. Наприклад функції які перевіряють дозволи для файлу, і після цього його відкривають.
Комунікаційна пов'язаність
частини модуля групуються тому що вони працюють з одними й тими ж даними.
Послідовна пов'язаність
частини модуля групуються тому, що вивід однієї частини передається на вхід іншої, як в конвеєрі. Наприклад функції що читають дані з файлу, обробляють їх, і пишуть назад.
Функціональна пов'язаність (найкраща)
частини модуля групуються тому, що вони разом працюють над одним, чітко означеним завданням для того модуля. Наприклад лексичний аналіз тексту чи XML.

Дослідження багатьох людей, таких як Ларрі Констянтин, Edward Yourdon, та Steve McConnell [2] показують що два перші види пов'язаності найгірші, комунікаційна та послідовна пов'язаності досить добрі і функціональна - найкраща, хоча не завжди досяжна. Бувають випадки, коли комунікаційна пов'язаність - це найкраще чого можна досягти при даних обставинах.

Див. також

[ред. | ред. код]

Джерела

[ред. | ред. код]
  • Yourdon, E.; Constantine, L L. (1979). Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. copyright 1979 by Prentice-Hall. Yourdon Press.
  1. W. Stevens, G. Myers, L. Constantine, “Structured Design”, IBM Systems Journal, 13 (2), 115-139, 1974.
  2. Code Complete 2nd Ed.

Посилання

[ред. | ред. код]