1. State

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

Паттерн складається із 3 блоків:

Context – клас, об'єкти якого повинні змінювати свою поведінку залежно від стану.

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

Для цього використовується подія (патерн Publisher – Subscriber). Це необхідно для того, щоб під час виконання програми замінювати об'єкт стану з появою подій. Можливі випадки, коли сам Context періодично опитує об'єкт стану на наявність переходу.

ConcreteState1, ConcreteState2 – класи конкретних станів. Повинні містити інформацію про те, за яких умов і в які стани може переходити об'єкт з поточного стану. Наприклад, з ConcreteState1 об'єкт може переходити в стан ConcreteState2 і ConcreteState3, а з ConcreteState2 – назад у ConcreteState1 тощо. Об'єкт одного з них повинен містити Context під час створення.

Наприклад, ти пишеш гру, де персонаж може бігати, плавати та літати. Якщо твій персонаж потрапив у воду, то розумно обмежити його поведінку у воді: він тепер не може стріляти, але в нього збереглися якісь дії: плисти вперед, праворуч, ліворуч тощо.

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

2. Strategy

Стратегія (Strategy) – поведінковий шаблон проєктування, призначений для визначення сімейства алгоритмів, інкапсуляції кожного з них та забезпечення їх взаємозамінності. Це дозволяє обирати алгоритм шляхом визначення відповідного класу.

Шаблон Strategy дозволяє змінювати обраний алгоритм незалежно від об'єктів-клієнтів, що його використовують.

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

Сильні сторони:

  • інкапсуляція реалізації різних алгоритмів; система стає незалежною від можливих змін бізнес-правил;
  • виклик всіх алгоритмів одним стандартним чином;
  • відмова від використання перемикачів та/або умовних операторів.

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

3. Template Method

Abstract class (абстрактний клас) – визначає абстрактні операції, що заміщуються у спадкоємцях для реалізації кроків алгоритму; реалізує шаблонний метод, що визначає скелет алгоритму. Шаблонний метод викликає заміщувані та інші, визначені в Abstract class, операції.

Concrete class (конкретний клас) – реалізує заміщувані операції необхідним для реалізації способом. Concrete class передбачає, що інваріантні кроки алгоритму виконаються в AbstractClass.

Цей патерн часто використовується, коли треба:

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

Так, цей патерн визначає використання пари: абстрактний клас та її реалізація.

4. Chain of Responsibility

Ланцюжок обов'язків (Chain of responsibility) – поведінковий шаблон проєктування, призначений для організації в системі рівнів відповідальності.

Шаблон рекомендований для використання в умовах, коли:

  • у системі, що розробляється, є група об'єктів, які можуть обробляти повідомлення певного типу;
  • усі повідомлення мають обробитися хоча б одним об'єктом системи;
  • повідомлення у системі обробляються за схемою “оброби сам чи перейшли іншому”, тобто одні повідомлення обробляються на тому рівні, де вони отримані, інші – пересилаються об'єктам іншого рівня.

5. Memento

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

Шаблон Зберігач використовується, коли:

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