Состояние - паттерн поведения объектов, задающий разную функциональность в зависимости от внутреннего состояния объекта. codelib.ru codelib.ru оригинал источник

Условия, Задача, Назначение

состояния. В этих подклассах TCPState реализуется поведение, специфичное для конкретного состояния. Например, в классах TCPEstablished и TCPClosed реализовано поведение, характерное для состояний Established и Closed соответственно. codelib.ru оригинал источник codelib.ru

источник codelib.ru codelib.ru оригинал

А при каждом изменении состояния соединения TCPConnection изменяет свой объект-состояние. Например, когда установленное соединение закрывается, TCPConnection заменяет экземпляр класса TCPEstablished экземпляром TCPClosed. источник codelib.ru codelib.ru оригинал

1. Когда поведение объекта зависит от его состояния и при этом должно изменяться во время выполнения. оригинал codelib.ru источник codelib.ru
2. Когда в коде операций встречаются состоящие из многих ветвей условные операторы, в которых выбор ветви зависит от состояния. Обычно в таком случае состояние представлено перечисляемыми константами. Часто одна и та же структура условного оператора повторяется в нескольких операциях.Паттерн состояние предлагает поместить каждую ветвь в отдельный класс. Это позволяет трактовать состояние объекта как самостоятельный объект, который может изменяться независимо от других. codelib.ru источник codelib.ru оригинал

Решение

оригинал источник codelib.ru codelib.ru

Участники паттерна Состояние (State)

1. Context (TCPConnection) – контекст.
   Определяет единый интерфейс для клиентов.
   Хранит экземпляр подкласса ConcreteState, которым определяется текущее состояние. codelib.ru источник оригинал codelib.ru
2. State (TCPState) – состояние.
   Определяет интерфейс для инкапсуляции поведения, ассоциированного с конкретным состоянием контекста Context. codelib.ru codelib.ru источник оригинал
3. Подклассы ConcreteState (TCPEstablished, TCPListen, TCPClosed) - конкретное состояние.
   Каждый подкласс реализует поведение, ассоциированное с некоторым состоянием контекста Context. codelib.ru оригинал источник codelib.ru

При этом либо Context, либо сами подклассы ConcreteState могут решить, при каких условиях и в каком порядке происходит смена состояний. источник codelib.ru оригинал codelib.ru

Вопросы, касающиеся реализации паттерна Состояние (State)

1. Что определяет переходы между состояниями.
   Паттерн состояние ничего не сообщает о том, какой участник определяет условия (критерии) перехода между состояниями. Если критерии зафиксированы, то их можно реализовать непосредственно в классе Context. Однако в общем случае более гибкий и правильный подход заключается в том, чтобы позволить самим подклассам класса State определять следующее состояние и момент перехода. Для этого в класс Context надо добавить интерфейс, позволяющий из объектов State установить его состояние.
   Такую децентрализованную логику переходов проще модифицировать и расширять – нужно лишь определить новые подклассы State. Недостаток децентрализации в том, что каждый подкласс State должен «знать» еще хотя бы об одном подклассе другого состояния (на которое собственно он и сможет переключить текущее состояние), что вносит реализационные зависимости между подклассами. оригинал источник codelib.ru codelib.ru
   codelib.ru источник codelib.ru оригинал
2. Табличная альтернатива.
   Существует еще один способ структурирования кода, управляемого сменой состояний. Это принцип конечного автомата. Он использует таблицу для отображения входных данных на переходы между состояниями. С ее помощью можно определить, в какое состояние нужно перейти при поступлении некоторых входных данных. По существу, тем самым мы заменяем условный код поиском в таблице.
   Основное преимущество автомата – в его регулярности: для изменения критериев перехода достаточно модифицировать только данные, а не код. Но есть и недостатки:
   - поиск в таблице часто менее эффективен, чем вызов функции,
   - представление логики переходов в однородном табличном формате делает критерии менее явными и, стало быть, более сложными для понимания,
   - обычно трудно добавить действия, которыми сопровождаются переходы между состояниями. Табличный метод учитывает состояния и переходы между ними, но его необходимо дополнить, чтобы при каждом изменении состоянии можно было выполнять произвольные вычисления.
   Главное различие между конечными автоматами на базе таблиц и Паттерн состояние можно сформулировать так: Паттерн состояние моделирует поведение, зависящее от состояния, а табличный метод акцентирует внимание на определении переходов между состояниями. codelib.ru источник оригинал codelib.ru
   источник codelib.ru оригинал codelib.ru
3. Создание и уничтожение объектов состояния.
   В процессе разработки обычно приходится выбирать между:
   - созданием объектов состояния, когда в них возникает необходимость, и уничтожением сразу после использования,
   - созданием их заранее и навсегда.
   
   Первый вариант предпочтителен, когда заранее неизвестно, в какие состояния будет попадать система, и контекст изменяет состояние сравнительно редко. При этом мы не создаем объектов, которые никогда не будут использованы, что существенно, если в объектах состояния хранится много информации. Когда изменения состояния происходят часто, поэтому не хотелось бы уничтожать представляющие их объекты (ибо они могут очень скоро понадобиться вновь), следует воспользоваться вторым подходом. Время на создание объектов затрачивается только один раз, в самом начале, а на уничтожение – не затрачивается вовсе. Правда, этот подход может оказаться неудобным, так как в контексте должны храниться ссылки на все состояния, в которые система теоретически может попасть. codelib.ru codelib.ru источник оригинал
   codelib.ru codelib.ru источник оригинал
4. Использование динамического изменения.
   Варьировать поведение по запросу можно, меняя класс объекта во время выполнения, но в большинстве объектно-ориентированных языков это не поддерживается. Исключение составляет Perl, JavaScript и другие основанные на скриптовом движке языки, которые предоставляют такой механизм и, следовательно, поддерживают Паттерн состояние напрямую. Это позволяет объектам варьировать поведение путем изменения кода своего класса. оригинал codelib.ru источник codelib.ru
   codelib.ru источник оригинал codelib.ru

1. Локализует зависящее от состояния поведение.
   И делит его на части, соответствующие состояниям. Паттерн состояние помещает все поведение, ассоциированное с конкретным состоянием, в отдельный объект. Поскольку зависящий от состояния код целиком находится в одном из подклассов класса State, то добавлять новые состояния и переходы можно просто путем порождения новых подклассов.
   Вместо этого можно было бы использовать данные-члены для определения внутренних состояний, тогда операции объекта Context проверяли бы эти данные. Но в таком случае похожие условные операторы или операторы ветвления были бы разбросаны по всему коду класса Context. При этом добавление нового состояния потребовало бы изменения нескольких операций, что затруднило бы сопровождение. Паттерн состояние позволяет решить эту проблему, но одновременно порождает другую, поскольку поведение для различных состояний оказывается распределенным между несколькими подклассами State. Это увеличивает число классов. Конечно, один класс компактнее, но если состояний много, то такое распределение эффективнее, так как в противном случае пришлось бы иметь дело с громоздкими условными операторами.
   Наличие громоздких условных операторов нежелательно, равно как и наличие длинных процедур. Они слишком монолитны, вот почему модификация и расширение кода становится проблемой. Паттерн состояние предлагает более удачный способ структурирования зависящего от состояния кода. Логика, описывающая переходы между состояниями, больше не заключена в монолитные операторы if или switch, а распределена между подклассами State. При инкапсуляции каждого перехода и действия в класс – состояние становится полноценным объектом. Это улучшает структуру кода и проясняет его назначение. codelib.ru оригинал источник codelib.ru
2. Делает явными переходы между состояниями.
   Если объект определяет свое текущее состояние исключительно в терминах внутренних данных, то переходы между состояниями не имеют явного представления; они проявляются лишь как присваивания некоторым переменным. Ввод отдельных объектов для различных состояний делает переходы более явными. Кроме того, объекты State могут защитить контекст Context от рассогласования внутренних переменных, поскольку переходы с точки зрения контекста – это атомарные действия. Для осуществления перехода надо изменить значение только одной переменной (объектной переменной State в классе Context), а не нескольких. codelib.ru источник оригинал codelib.ru
3. Объекты состояния можно разделять.
   Если в объекте состояния State отсутствуют переменные экземпляра, то есть представляемое им состояние кодируется исключительно самим типом, то разные контексты могут разделять один и тот же объект State. Когда состояния разделяются таким образом, они являются, по сути дела, приспособленцами (см. паттерн-приспособленец), у которых нет внутреннего состояния, а есть только поведение. codelib.ru оригинал codelib.ru источник

Прежде всего определим класс TCPConnection, который предоставляет интерфейс для передачи данных и обрабатывает запросы на изменение состояния: TCPConnection. источник оригинал codelib.ru codelib.ru

Известные применения паттерна Состояние (State)

codelib.ru оригинал источник codelib.ru