Змістовий модуль 4. Шаблони конструювання (патерни)

Лекція 6. Шаблони конструювання.

Література: 1 [71-79]; 2[223-253];7; 12

Класифікація шаблонів. Шаблони проектування. Розподіл обов’язків у системі.

Шаблон Контролер. Шаблон Творець.

Визначення патерна. Класифікація патернів

У процесі розробки програмних систем і моделювання бізнес-процесів виникає багато проблем, які мають однакові або схожі схеми рішення. Спроби виявити схожі проблеми й запропонувати для їхнього рішення схеми або структури на підставі успішного досвіду роботи над проектами в рамках об’єктно-орієнтованого аналізу й проектування привели до появи поняття патерна, що з абстрактної категорії перетворилося в неодмінний елемент сучасних технологій створення ПЗ.

Існує наступна загальна класифікація патернів по категоріях їхнього застосування : · архітектурні патерни;

· патерни проектування;

· патерни аналізу; · патерни тестування; · патерни реалізації.

Архітектурні патерни (Architectural patterns) призначені для специфікації фундаментальних схем структуризації програмних систем.

Патерни проектування (Design patterns) – спеціальні схеми для уточнення структури підсистем або компонентів програмної системи й відносин між ними.

Патерни аналізу (Analysis patterns) – спеціальні схеми для представлення загальної організації процесу моделювання.

Патерни тестування (Test patterns) – спеціальні схеми для представлення загальної організації процесу тестування програмних систем.

Патерни реалізації (Implementation patterns) – сукупність компонентів і інших елементів реалізації, використовуваних у структурі моделі при написанні програмного коду.

Опис патернів

Опис патерна містить три обов'язкові частини: назва, проблема й рішення. Часто опис супроводжується також обговоренням результатів використання патерна й прикладом.

Патерн Контролер (Controller)

Проблема: Хто повинен відповідати за обробку вхідних системних подій?

Рішення: Поставити обов'язок по обробці системних повідомлень класу, що задовольняє одній з наступних умов:

• клас представляє всю систему в цілому, пристрій або підсистему (зовнішній контролер)

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

Патерн Творець (Creator)

Проблема: Хто повинен відповідати за створення нового екземпляра деякого класу?

Рішення: Призначити класу В обов'язок створювати екземпляри класу А, якщо виконується одна з наступних умов: - клас В агрегує об'єкти А;

• клас В містить об'єкт класу А;

• клас В записує об'єкти класу А;

• клас В активно використає об'єкти А;

• клас В має дані ініціалізації, які будуть передаватися об'єктам А при їхньому створенні (тобто при створенні об'єктів класу А клас В є експертом).

Контрольні запитання

1. Що таке патерни (шаблони) у створенні ПЗ?

2. Які категорії патернів ви знаєте?

3. Який формат застосовують для опису патерна?

4. Яку проблему вирішує патерн Контролер (Controller)?

5. Яку проблему вирішує патерн Творець (Creator)?

Лекція 7. Шаблони конструювання (продовження).

Література:1 [71-79]; 2[223-253];7; 12

Шаблон Інформаційний інспектор. Шаблон Слабке зв’язування. Шаблон Високе зачеплення.

Патерн Інформаційний експерт (Information Expert )

Проблема: У моделі можуть бути визначені десятки й сотні програмних класів, а в застосуванні може знадобитися виконання сотень і тисяч обов'язків. Необхідно розподілити обов'язки між класами.

Рішення: Призначити обов'язки інформаційного експерта класу, у якого є інформація, необхідна для виконання обов'язків.

Патерн Інформаційний експерт використовується набагато частіше інших шаблонів. Аналогією в реальному світі є розподіли обов'язків між працівниками.

Патерн Інформаційний експерт пов'язаний із патернами Слабке зв'язування й Високе зачеплення.

Патерн Слабке зв'язування (Low Coupling)

Проблема: Як забезпечити залежність, незначний вплив змін і підвищити можливість повторного використання?

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

Клас із високим ступенем зв'язаності породжує наступні проблеми:

• зміни у зв'язаних класах приводять до локальних змін у даному класі;

• ускладнюється розуміння кожного класу окремо;

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

Рішення: Розподілити обов'язки таким чином, щоб ступінь зв'язаності залишалася низкою.

Не існує абсолютної міри для визначення занадто високого ступеня зв'язування. І повне, й дуже слабке зв'язування між класами небажані.

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

З Low Coupling зв'язаний патерн Protected Variations.

Патерн High Cohesion (високе зачеплення)

Проблема: як забезпечити можливість керування складністю?

Зачеплення – це міра зв'язаності й зфокусованості обов'язків класу.

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

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

Рішення: Розподіл обов'язків, що забезпечує високий ступінь зачеплення.

Зв'язування й зачеплення – це старі принципи проектування програмних продуктів. Модульне проектування забезпечується за рахунок створення методів і класів з високим зачепленням. На рівні базових об'єктів модульність досягається за рахунок проектування кожного методу з явно виділеною конкретною метою й групування набору взаємозалежних методів у рамках одного класу.

Некоректне зв'язування породжує неправильне зачеплення, й навпаки.

Патерн не слід застосовувати, коли обов'язки або код групуються в одному класі з метою спрощення процедури його обслуговування. Наприклад, розміщення в одному класі множини операторів SQL може спростити його обслуговування фахівцем з баз даних.

Контрольні запитання

1. Яку проблему вирішує патерн Інформаційний експерт (Information Expert )?

2. Яку проблему вирішує патерн Слабке зв'язування (Low Coupling)?

3. Яку проблему вирішує патерн Високе зачеплення (High Cohesion)?

4. Яку проблему вирішує патерн Поліморфізм (Polymorphism)?

5. Яку проблему вирішує патерн Штучний клас (Pure fabrication)?

6. Яку проблему вирішує патерн Перенапрямок (Indirection)?

7. Яку проблему вирішує патерн Стратегія (Strategy)?

8. Яку проблему вирішує патерн Захист від змін (Protected Variations)?

9. У чому полягає проектування на основі даних?

10. У чому полягає проектування на основі інтерпретаторів?

11. Що декларує принцип підстановки Лискова?

Приклад застосування патерна Information Expert

У системі RTS деякому класу необхідно доручити визначення вартості квитка.

Починати розподіл обов'язків треба з їхнього чіткого формулювання: який клас повинен відповідати за знання вартості квитка?

Відповідно до патерна Information Expert, потрібно визначити, об'єкти яких класів містять інформацію, необхідну для обчислення вартості.

Яка модель дозволить виконати аналіз? Модель предметної області або проектування?

Припустимо, що ми перебуваємо на самому початку етапу проектування, коли модель проектування представлена в мінімальному обсязі. Отже, необхідно звернутися до предметної області. На рис. 7.1 представлений відповідний фрагмент моделі предметної області.

Рис. 7.1 Фрагмент моделі предметної області

Для визначення вартості квитка необхідно знати станцію відправлення й призначення, клас поїзда й місця. Цією інформацією володіє об'єкт класу Order. Тому він повинен бути обраний як інформаційний експерт і йому повинне бути адресоване повідомлення getPrice().

Тепер з'ясовуємо, який клас може визначити ціну квитка залежно від відстані між станціями, класу поїзда й місця, а також установлених тарифів. Таким класом є Payment. Він у свою чергу є інформаційним експертом. Йому потрібно адресувати аналогічне повідомлення, але в цьому випадку воно повинне містити параметри. Об'єкт класу Payment у свою чергу для визначення відстані між станціями повинен звернутися до об'єкта класу Way, а потім до об'єкта класу Tariff, де є співвідношення відстані й вартості, націнки на класність поїзда й місця, можливо й інші бізнес-правила, наприклад залежності ціни від сезону й т.д. Використовуючи цю інформацію, об'єкт Payment одержує можливість розрахувати вартість квитка. У термінах діаграм взаємодій це означає, що об'єкт Payment повинен передати повідомлення getDistance об'єкту Way і getTariff() об'єкту Tariff , а потім зробити розрахунок (див. рис. 7.2).

Рис. 7.2 Визначення вартості квитка