Стан (шаблон проєктування)

Стан (англ. state) — шаблон проєктування (належить до шаблонів поведінки), що реалізує скінченний автомат в обʼєктно-орієнтованому програмуванні.

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

Призначення[ред. | ред. код]

Дозволяє об'єктові варіювати свою поведінку залежно від внутрішнього стану.

Застосовність[ред. | ред. код]

Слід використовувати шаблон Стан у випадках, коли:

  • поведінка об'єкта залежить від його стану та повинна змінюватись під час виконання програми;
  • у коді операцій зустрічаються складні умовні оператори, у котрих вибір гілки залежить від стану. Зазвичай у такому разі стан представлено константами, що перелічуються. До того ж часто одна й та ж структура умовного оператору повторюється у декількох операціях. Шаблон Стан пропонує замінити кожну гілку окремим класом. Це дозволить трактувати стан об'єкта як самостійний об'єкт, котрий може змінитися незалежно від інших.

Структура[ред. | ред. код]

UML діаграма, що описує структуру шаблону проєктування Стан
  • Context — контекст:
    • визначає інтерфейс, що є корисним для клієнтів;
    • зберігає екземпляр підкласу ConcreteState, котрим визначається поточний стан;
  • State — стан:
    • визначає інтерфейс для інкапсуляції поведінки, асоційованої з конкретним станом контексту Context;
  • Підкласи ConcreteState — конкретні стани:
    • кожний підклас реалізує поведінку, асоційовану з деяким станом контексту Context.

Відносини[ред. | ред. код]

  • клас Context делегує залежні від стану запити до поточного об'єкта ConcreteState;
  • контекст може передати себе як аргумент об'єкта State, котрий буде обробляти запит. Це надає можливість об'єкта-стану при необхідності отримати доступ до контексту;
  • Context — це головний інтерфейс для клієнтів. Клієнти можуть конфігурувати контекст об'єктами стану State. Один раз сконфігурувавши контекст, клієнти вже не повинні напряму зв'язуватися з об'єктами стану;
  • або Context, або підкласи ConcreteState можуть вирішити, за яких умов та у якій послідовності відбувається зміна станів.

Переваги та недоліки[ред. | ред. код]

Переваги[ред. | ред. код]

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

Недоліки[ред. | ред. код]

  • Зростає кількість класів

Зв'язок з іншими патернами[ред. | ред. код]

  • В стратегії користувач знає про класи стратегій і міняє їх самостійно, в стані різноманітні стани приховані від користувача, а за їх заміну відповідає сам клас


Реалізація[ред. | ред. код]

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

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

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

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

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

Джерела[ред. | ред. код]

Література[ред. | ред. код]

Алан Шаллоуей, Джеймс Р. Тротт. Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию = Design Patterns Explained: A New Perspective on Object-Oriented Design. — М. : «Вильямс», 2002. — 288 с. — ISBN 0-201-71594-5.