 |
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция
Особливості програмної реалізації. Паттерн Стан нічого не повідомляє про те, який учасник визначає критерій переходу між станами
Паттерн Стан нічого не повідомляє про те, який учасник визначає критерій переходу між станами. Якщо критерії зафіксовані, то їх можна реалізувати безпосередньо в класі Context. Однак у загальному випадку більш гнучкий і правильний підхід полягає в тому, щоб дозволити самим підкласами класу State визначати наступний стан і момент переходу. Для цього в клас Context треба додати інтерфейс, що дозволяє об’єктам State встановити стан контексту. Таку децентралізовану логіку переходів простіше змінювати і розширювати – потрібно лише визначити нові підкласи State. Недолік децентралізації полягає в тому, що кожний підклас State повинен «знати» ще хоча б про один підклас, що вносить реалізаційні залежності між підкласами.
В процесі розробки, зазвичай, доводиться вибирати між: створенням об’єктів стану, коли в них виникає необхідність, і знищенням відразу після використання або створенням їх заздалегідь і назавжди.
Результати використання. При застосуванні паттерна Стан можна розраховувати на наступні результати [12]:
- локалізує залежну від стану поведінку і ділить її на частини, що відповідають підкласам Стану. Паттерн Стан поміщає всю поведінку, яка асоціюється з конкретним станом, в окремий об’єкт. Оскільки код, який залежить від стану, цілком знаходиться в одному з підкласів класу State, то додавати нові стани та переходи можна просто шляхом породження нових підкласів;
- робить явними переходи між станами. Якщо об’єкт визначає свій поточний стан винятково в термінах внутрішніх даних, то переходи між станами не мають явного представлення, вони виявляються лише як присвоювання деяким змінним. Введення окремих об’єктів для різних станів робить переходи більш явними. Крім того, об’єкти State можуть захистити Context від неузгодженості внутрішніх змінних, оскільки переходи з погляду контексту – це атомарні дії. Для здійснення переходу треба змінити значення тільки однієї змінної (об’єктної змінної State у класі Context), а не декількох;
- об’єкти стану можна розділяти. Якщо в об’єкті State відсутні змінні екземпляра, тобто стан, що їм описується, кодується винятково самим типом, то різні контексти можуть розділяти той самий об’єкт State.
Діаграми класів паттернів Стратегія і Стан практично збігаються, але ці два паттерни розрізняються своєю метою (табл. 6.1). В паттерні Стратегія клієнт зазвичай визначає об’єкт стратегії, що пов’язується з контекстом. Хоча паттерн забезпечує необхідну гнучкість для зміни об’єкта стратегії під час виконання, часто в програмі існує об’єкт стратегії, найбільш підходящий для об’єкта контексту.
Таблиця 6.1. Порівняльна характеристика Стану та Стратегія
| Стратегія | Стан |
| Є клас, екземпляр якого створює паттерн. Цьому екземпляру зазвичай передаються об’єкти стратегії, що | При створенні об’єктів контексту їм можна задавати вихідний стан, який вони можуть з часом змінювати. |
| Продовження табл. 6.1. | |
| реалізують деяку поведінку. Зазвичай, керує тим, яку стратегію використовують об’єкти. | Об’єкти-конкретні стани змінюють свій стан з чітко визначеними переходами. Зміна поведінки вбудована в схему роботи паттерну. |
Паттерн Шаблонний метод (Template method)
Призначення. Паттерн Шаблонний метод – це паттерн поведінки, що визначає основу алгоритму і дозволяє підкласам перевизначити деякі кроки алгоритму, не змінюючи його структуру в цілому [30].
Частота використання 
Мотивація застосування. Є два різних, але в той же час дуже схожих компонента. Ви хочете внести зміни в обидва компоненти, уникнувши дублювання коду.
Рекомендовано застосовувати паттерн Шаблонний метод у наступних випадках:
- щоб одноразово використовувати інваріантні частини алгоритму, залишаючи реалізацію змінної поведінки на розсуд підкласів;
- коли потрібно відокремити і локалізувати в одному класі поведінку, загальну для всіх підкласів, щоб уникнути дублювання коду.
Проектувальник компонента вирішує, які кроки алгоритму є незмінними (або стандартними), а які змінними (або власними). Абстрактний базовий клас реалізує стандартні кроки алгоритму і може надавати (або ні) реалізацію за замовчуванням для власних кроків. Змінні кроки можуть (або повинні) надаватись клієнтом компонента в конкретних похідних класах.
Проектувальник компонента визначає необхідні кроки алгоритму, порядок їх виконання, але дозволяє клієнтам компонента розширювати чи замінювати деякі з цих кроків.
Паттерн Template Method широко застосовується в каркасах додатків (frameworks). Кожний каркас реалізує незмінні частини архітектури в предметній області, а також визначає ті частини, які можуть або повинні налаштовуватися клієнтом.
Діаграма класів паттерна Шаблонний метод представлена на рис. 6.37.
Рис. 6.37. Діаграма класів паттерна Шаблонний метод
Поиск по сайту: