Частота использования: 3 из 5
Решаемая проблема: Поведение объекта зависит от его состояния и должно изменяться во время выполнения программы. Такую схему можно реализовать, применив множество условных операторов: на основе анализа текущего состояния объекта предпринимаются определенные действия. Однако при большом числе состояний условные операторы будут разбросаны по всему коду, и такую программу будет трудно поддерживать.
Паттерн State решает указанную проблему следующим образом: - Вводит класс Context, в котором определяется интерфейс для внешнего мира. - Вводит абстрактный класс State. - Представляет различные "состояния" конечного автомата в виде подклассов State. - В классе Context имеется указатель на текущее состояние, который изменяется при изменении состояния конечного автомата.
Мотивация: использовать паттерна когда: - когда поведение объекта зависит от его состояния и должно изменяться во время - когда в коде операций встречаются состоящие из многих ветвей условные
Диаграмма классов:
Участники: Context (TCPConnection) - контекст: - определяет интерфейс, представляющий интерес для клиентов; - хранит экземпляр подкласса ConcreteState, которым определяется текущее State (TCPState) - состояние: - определяет интерфейс для инкапсуляции поведения, ассоциированного с Подклассы ConcreteState (TCPEstablished, TCPListen, TCPClosed) - конкретное состояние: - каждый подкласс реализует поведение, ассоциированное с некоторым состоянием
Отношения: Класс Context определяет внешний интерфейс для клиентов и хранит внутри себя ссылку на текущее состояние объекта State. Интерфейс абстрактного базового класса State повторяет интерфейс Context за исключением одного дополнительного параметра -указателя на экземпляр Context. Производные от State классы определяют поведение, специфичное для конкретного состояния. Класс "обертка" Context делегирует все полученные запросы объекту "текущее состояние", который может использовать полученный дополнительный параметр для доступа к экземпляру Context. Пример паттерна State: Паттерн State позволяет объекту изменять свое поведение в зависимости от внутреннего состояния. Похожая картина может наблюдаться в работе торгового автомата. Автоматы могут иметь различные состояния в зависимости от наличия товаров, суммы полученных монет, возможности размена денег и т.д. После того как покупатель выбрал и оплатил товар, возможны следующие ситуации (состояния): - Выдать покупателю товар, выдавать сдачу не требуется. - Выдать покупателю товар и сдачу. - Покупатель товар не получит из-за отсутствия достаточной суммы денег. - Покупатель товар не получит из-за его отсутствия. Результаты применения паттерна: - локализует зависящее от состояния поведение и делит его на части,, Реализация: - Паттерн состояние ничего не сообщает о том, какой участник определяет критерий перехода между состояниями. Если критерии зафиксированы, то их можно реализовать непосредственно в классе Context. Однако в общем случае более гибкий и правильный подход заключается в том, чтобы позволить самим подклассам класса State определять следующее состояние и момент перехода. Для этого в класс Context надо добавить интерфейс, позволяющий объектам State установить состояние контекста. Такую децентрализованную логику переходов проще модифицировать и расширять - нужно лишь определить новые подклассы State. Недостаток децентрализации в том, что каждый подкласс State должен «знать» еще хотя бы об одном подклассе, что вносит реализационные зависимости между подклассами; - создание и уничтожение объектов состояния. В процессе разработки обычно приходится выбирать между: - созданием объектов состояния, когда в них возникает необходимость, и - созданием их заранее и навсегда. Диаграммы классов паттернов Стратегия и Состояние практически совпадают, но эти два паттерна различаются своей целью. В паттерне Состояние набор вариантов поведения инкапсулируется в объектах состояния; в любой момент времени контекст делегирует выполнение действий одному из этих объектов. Со временем текущее состояние переключается на другие объекты в соответствии с изменениями внутреннего состояния контекста, так что поведение контекста также изменяется со временем. При этом клиент обычно знает об объектах состояния очень мало (или вообще ничего не знает). В паттерне Стратегия клиент обычно определяет объект стратегии, связываемый с контекстом. Хотя паттерн обеспечивает необходимую гибкость для изменения объекта стратегии во время выполнения, часто имеется объект стратегии, наиболее подходящий для объекта контекста.
using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace ex { //state
public interface Iexperience { void DoBattle (Warrior w); }
//context public class Warrior { private Iexperience ex = new Weak(); public void Battle() { ex.DoBattle(this); //изменение здоровья } public void Setexperience(Iexperience ex) { this.ex = ex; } public void Showexperience() { Console.WriteLine("Теперь опыт воина: " + ex.GetType().ToString()); } }
public class SuperStrong: Iexperience { public void DoBattle(Warrior w) { w.Setexperience(new SuperStrongO); } }
public class Strong: Iexperience { public void DoBattle(Warrior w) { w.Setexperience(new SuperStrongO); } }
public class Normal: Iexperience { public void DoBattle(Warrior w) { w.Setexperience(new StrongO); } }
public class Weak: Iexperience { public void DoBattle(Warrior w) { w.Setexperience(new Normal()); } }
class Program static void Main(string[] args) { Warrior w - new Warrior(); w. ShowexperienceO; w.BattleO; w. ShowexperienceO; w.Battle(); w. ShowexperienceO; w.Battle(); w.ShowexperienceO; w.Battle(); w. ShowexperienceO; Console.ReadLineO; } } }
|
