Компоненти проектування

При об’єктно-орієнтованому підході слід визначити:

a. Об’єкти та їх атрибути (методи і дані);

b. Дії, що можуть бути виконані над кожним об’єктом;

c. Дії, що кожен об’єкт може виконувати над іншими об’єктами (включення та наслідування);

d. Частини кожного об’єкта, які будуть видимі іншим об’єктам;

e. Відкритий інтерфейс кожного об’єкта (дані та методи, що об’єкт надає у користування решті об’єктів).

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

1) Визначаються. Якщо обрано адекватні вимоги, вони містять і список потенційних змін та оцінку ймовірності кожної з них. Інакше можна виділити кілька областей, що часто змінюються:

· бізнес-правила,

· залежність від обладнання (наприклад, інтерфейс між програмою та різними типами моніторів, принтерів, клавіатур та ін.),

· введення-виведення (якщо програма створює власні файли даних, її ускладнення може потребувати зміни їх форматів),

· нестандартні можливості мови (в іншому середовищі, апаратній платформі, реалізаціях мови вони можуть виявитись недоступними),

· складні аспекти проектування та конструювання (їх часто доводиться реалізовувати заново);

· змінні статусу (характеризують стан програми, в їх якості краще використовувати не булеві змінні, а перечислення, при цьому замість безпосередньої перевірки використовувати методи доступу). Наприклад, якщо потрібно перевіряти комбінацію змінної статусу помилки та змінної поточного функціонального стану, легше реалізувати перевірку, заховану в методі, ніж жорстко закодувати в багатьох місцях програми;

· розміри структур даних (наприклад, при оголошенні масиву на 100 елементів краще використовувати іменовану константу, ніж число).

2) Відділяються. Створюється окремий клас для кожного нестабільного компонента (або навіть кількох компонентів, якщо їх доведеться змінювати одночасно) з пункту 1.

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

Існує наступна методика визначення областей ймовірних змін. Спочатку потрібно визначити мінімальну підмножину фрагментів програми, необхідних користувачам. Ця підмножина складе ядро програми і його зміни малоймовірні. Потім визначаються мінімальні (навіть тривіальні) інкрементні прирощення системи. Разом із функціональними змінами слід розглядати якісні зміни програми: забезпечення безпеки у багато поточному середовищі, підтримку механізмів локалізації та ін. Визначивши ядро на початку, легко зрозуміти, які компоненти системи насправді є доповненнями.

При проектуванні важливо створювати класи та методи, що мають небагато безпосередніх, явних та гнучких відношень з іншими класами. Це називається «слабким спряженням» (loose coupling). Наприклад, метод sin() слабко спряжений, оскільки отримує один параметр – радіанну міру кута. Метод InitVars (var1, var2, var3, …, varN)спряжений жорсткіше, оскільки багато деталей його роботи стають відомими модулю (тобто, класу чи методу), який його викликає, по значенням, що передаються. Два класи, залежних від глобальної змінної спряжені ще жорсткіше. Оцінити спряження модулів дозволяють кілька критеріїв:

· Об’єм – кількість з’єднань між модулями. Чим компактніший інтерфейс модуля, тим легше зв’язати його з іншими модулями;

· Видимість – помітність зв’язків між 2 модулями. Передача даних у вигляді списку параметрів – вдалий варіант, оскільки формує очевидний зв’язок. Передача даних іншому модулю в глобальних даних є замаскованою, а тому невдалим зв’язком. Більш вдало використовувати опис зв’язку через глобальні дані в документації – це робить зв’язок більш явним.

· Гнучкість – характеризує легкість зміни зв’язку між модулями. Тобто, чим простіше викликати модуль з інших модулів, тим слабше він спряжений, гнучкіший та простіший при супроводженні.

Нижче описано розповсюджені види спряження:

· Просте спряження за допомогою даних-параметрів (між модулями передаються лише елементарні типи даних через списки параметрів);

· Просте спряження за допомогою об’єкта (модуль спряжений таким способом, якщо він створює екземпляр даного об’єкта);

· Спряження за допомогою об’єкта-параметра (об’єкт1 вимагає, щоб об’єкт2 передав йому об’єкт3). Такий тип спряження жорсткіший, ніж попередні;

· Семантичне спряження. Прикладами такого спряження є:

o Модуль1 передає в Модуль2 управляючий прапор (flag), що визначає подальшу поведінку Модуля2. Тобто Модуль1 повинен робити припущення з приводу роботи Модуля2;

o Модуль2 використовує глобальні дані після їх зміни Модулем1. При цьому Модуль2 припускає, що Модуль1 було викликано вчасно, а глобальні дані змінено саме так, як потрібно Модулю2;

o Інтерфейс Модуля1 стверджує, що метод Module1.Initialize() повинен викликатися до методу Module1.Routine(). Модуль2 знає, що Module1.Routine() викликає Module1.Initialize(), тому він просто створює екземпляр Модуля1 і викликає Module1.Routine() без попереднього виклику методу Module1.Initialize();

o Модуль1 передає в Модуль2 Об’єкт. Модуль1 знає, що Модуль2 використовує 3 методи Об’єкта з 7, тому він ініціалізує Об’єкт частково, лише даними, необхідними цим трьом методам;

o Модуль1 передає в Модуль2 Базовий Об’єкт. Модуль2 знає, що насправді Модуль1 передав йому Похідний Об’єкт, тому він приводить тип Базового Об’єкта до типу Похідного об’єкта і викликає методи, специфічні для Похідного Об’єкта.

Семантичне спряження небезпечно тим, що зміна коду в Модулі1 може так порушити роботу Модуля2, що компілятор цього не зможе визначити.

Дата добавления: 2014-01-07