Состояние на Java. Шаблон проектирования «состояние» двадцать лет спустя Различия между паттернами Стратегия и Состояние в Java
Для того, чтобы правильно использовать паттерны Состояние и Стратегия в ядре Java приложений, важно для Java-программистов четко понимать разницу между ними. Хотя оба шаблона, Состояние и Стратегия, имеют схожую структуру, и оба основаны на принципе открытости/закрытости, представляющие ”O” в SOLID принципах , они совершенно разные по намерениям . Паттерн Стратегия в Java используется для инкапсуляции связанных наборов алгоритмов для обеспечения гибкости исполнения для клиента. Клиент может выбрать любой алгоритм во время выполнения без изменения контекста класса, который использует объект Strategy . Некоторые популярные примеры паттерна Стратегия – это написание кода, который использует алгоритмы, например, шифрование, сжатие или сортировки. С другой стороны, паттерн Состояние позволяет объекту вести себя по-разному в разном состоянии. Поскольку в реальном мире объект часто имеет состояния, и он ведет себя по-разному в разных состояниях, например, торговый автомат продает товары только если он в состоянии hasCoin , он не продает до тех пор пока вы не положите в него монету. Сейчас вы можете ясно видеть разницу между паттернами Стратегия и Состояние, это различные намерения. Паттерн Состояние помогает объекту управлять состоянием, тогда как паттерн Стратегия позволяет выбрать клиенту другое поведение. Еще одно отличие, которое не так легко увидеть, это кто управляет изменением в поведении. В случае паттерна Стратегия, это клиент, который предоставляет различные стратегии к контексту, в паттерне Состояние переходом управляет контекст или состояние объекта самостоятельно. Кроме того, если вы управляете изменениями состояний в объекте Состояние самостоятельно, должна быть ссылка на контекст, например, в торговом автомате должна быть возможность вызвать метод setState() для изменения текущего состояния контекста. С другой стороны, объект Стратегия никогда не содержит ссылку на контекст, сам клиент передает Стратегию своего выбора в контекст. Разница между паттернами Состояние и Стратегия один из популярных вопросов о паттернах Java на интервью , в этой статье о паттернах Java мы подробней рассмотрим это. Мы будем исследовать некоторые сходства и различия между паттернами Стратегия и Состояние в Java, которые помогут вам улучшить ваше понимание этих паттернов.
Сходства между паттернами Состояние и Стратегия
Если вы посмотрите на UML-диаграмму паттернов Состояние и Стратегия, можно заметить, что оба выглядят похоже друг на друга. Объект, который использует Состояние для изменения своего поведения известен как Context -объект, аналогично объект, который использует Стратегию чтобы изменить свое поведение упоминается как Context -объект. Запомните, что клиент взаимодействует с Context -объектом. В случае паттерна Состояние контекст делегирует методы вызова объекту Состояние, который удерживается в виде текущего объекта, а в случае паттерна Стратегия контекст использует объект Стратегии в качестве параметра или предоставляется во время создания контекста объекта. UML диаграмма паттерна Состояние в Java- Оба паттерна, Состояние и Стратегия, делают несложным добавление нового состояния и стратегии не затрагивая контекст объекта, который использует их.
- Оба из них поддерживают ваш код в соответствии с принципом открытости/закрытости , то есть дизайн будет открыт для расширений, но закрыт для модификации. В случае паттернов Состояние и Стратегия, контекст объекта закрыт для модификаций, введений новых Состояний или новых Стратегий, либо вы не нуждаетесь в модификации контекста другого состояния, или минимальных изменениях.
- Также как контекст объекта начинается с состояния инициализации объекта в паттерне Состояние, контекст объекта также имеет стратегию по умолчанию в случае паттерна Стратегия в Java.
- Паттерн Состояние представляет различные поведения в форме различных состояний объекта, в то время как паттерн Стратегия представляет различное поведение в виде различных стратегий объекта.
- Оба паттерна, Стратегия и Состояние, зависят от подклассов реализации поведения. Каждая конкретная стратегия расширяет Абстрактную Стратегию, каждое состояние есть подкласс интерфейса или абстрактного класса , который используется для преставления Состояния.
Различия между паттернами Стратегия и Состояние в Java
Итак, теперь мы знаем, что паттерны Состояние и Стратегия похожи по структуре, а их намерения различны. Давайте рассмотрим некоторые ключевые различия между этими шаблонами проектирования.- Паттерн Стратегия инкапсулирует набор связанных алгоритмов, и позволяет клиенту использовать взаимозаменяемые поведения несмотря на состав и делегирование во время выполнения, с другой стороны паттерн Состояние помогает классу демонстрировать различные поведения в различных состояниях.
- Следующая разница между паттернами Состояние и Стратегия состоит в том, что Состояние инкапсулирует состояние объекта, тогда как паттерн Стратегия инкапсулирует алгоритм или стратегию. Поскольку состояние связано с объектом оно не может быть повторно использовано, но отделяя стратегию или алгоритм из контекста мы можем использовать его повторно.
- В паттерне Состояние личное состояние может содержать ссылку на контекст для реализации переходов между состояниями, но Стратегия не содержит ссылку на контекст где она используется.
- Реализация Стратегии может быть передана как параметр объекту, который будет использовать ее, например, Collection.sort() принимает Comparator , который является стратегией. С другой стороны, состояние является частью самого контекста объекта, и в течение долгого времени контекст объекта переходит из одного состояния в другое.
- Хотя и Стратегия и Состояние следуют принципу открытости/закрытости, Стратегия также следует Принципу Единственной Обязанности так как каждая Стратегия содержит индивидуальный алгоритм, различные стратегии независимы друг от друга. Изменение одной стратегии не требует изменения другой стратегии.
- Еще одно теоретическое отличие между паттернами Стратегия и Состояние заключается в том, что создатель определяет часть объекта “Как”, например, “Как” объект сортировки сортирует данные, с другой стороны паттерн Состояние определяет части “что” и “когда” в объекте, например, что может объект когда он находится в определенном состоянии.
- Порядок перехода состояния хорошо определен в паттерне Состояние, такого требования нет к паттерну Стратегия. Клиент волен в выборе любой реализации Стратегии на его выбор.
- Некоторые из общих примеров паттерна Стратегия – это инкапсуляция алгоритмов, например, алгоритмы сортировки, шифрования или алгоритм сжатия. Если вы видите, что ваш код должен использовать различные виды связанных алгоритмов, следует подумать об использовании паттерна Стратегия. С другой стороны, распознать возможность использования паттерна Состояние довольно легко, если вам нужно управлять состоянием и переходами между состояниями без большого количества вложенных условных операторов паттерн Состояние – нужный паттерн для использования.
- Последнее, но одно из наиболее важных различий между паттернами Состояние и Стратегия заключается в том, что изменение Стратегии выполняется Клиентом, а изменение Состояния может быть выполнено контекстом или состоянием объекта самостоятельно.
using System;
namespace State
{
///
Поведенческий шаблон проектирования. Используется в тех случаях, когда во время выполнения программы объект должен менять своё поведение в зависимости от своего состояния. Классическая реализация предполагает создание базового абстрактного класса или интерфейса, содержащего все методы и по одному классу на каждое возможно состояние. Шаблон представляет собой частный случай рекомендации «заменяйте условные операторы полиморфизмом ».
Казалось бы, все по книжке, но есть нюанс. Как правильно реализовать методы не релевантные для данного состояния? Например, как удалить товар из пустой корзины или оплатить пустую корзину? Обычно каждый state-класс реализует только релевантные методы, а в остальных случаях выбрасывает InvalidOperationException .
Нарушение принципа подстановки Лисков на лицо. Yaron Minsky предложил альтернативный подход : сделайте недопустимые состояния непредставимыми (make illegal states unrepresentable)
. Это дает возможность перенести проверку ошибок со времени исполнения на время компиляции. Однако control flow в этом случае будет организован на основе сопоставления с образцом, а не с помощью полиморфизма. К счастью, .
Более подробно на примере F# тема make illegal states unrepresentable раскрыта на сайте Скотта Влашина .
Рассмотрим реализацию «состояния» на примере корзины. В C# нет встроенного типа union . Разделим данные и поведение. Само состояние будем кодировать с помощью enum, а поведение отдельным классом. Для удобства объявим атрибут, связывающий enum и соответствующий класс поведения, базовый класс «состояния» и допишем метод расширения для перехода от enum к классу поведения.
Инфраструктура
public class StateAttribute: Attribute { public Type StateType { get; } public StateAttribute(Type stateType) { StateType = stateType ?? throw new ArgumentNullException(nameof(stateType)); } } public abstract class StateПредметная область
Объявим сущность «корзина»:Public interface IHasState
Реализуем по одному классу на каждое состояние корзины: пустую, активную и оплаченную, но не будем объявлять общий интерфейс. Пусть каждое состояние реализует только релевантное поведение. Это не значит, что классы EmptyCartState , ActiveCartState и PaidCartState не могут реализовать один интерфейс. Они могут, но такой интерфейс должен содержать только методы, доступные в каждом состоянии. В нашем случае метод Add доступен в EmptyCartState и ActiveCartState , поэтому можно унаследовать их от абстрактного AddableCartStateBase . Однако, добавлять товары можно только в неоплаченную корзину, поэтому общего интерфейса для всех состояний не будет. Таким образом мы гарантируем отсутствие InvalidOperationException в нашем коде на этапе компиляции.
Public partial class Cart
{
public enum CartStateCode: byte
{
Empty,
Active,
Paid
}
public interface IAddableCartState
{
ActiveCartState Add(Product product);
IEnumerable
Состояния объявлены вложенными (nested
) классами не случайно. Вложенные классы имеют доступ к защищенным членам класса Cart , а значит нам не придется жертвовать инкапсуляцией сущности для реализации поведения. Чтобы не мусорить в файле класса сущности я разделил объявление на два: Cart.cs и CartStates.cs с помощью ключевого слова partial .
Public ActionResult GetViewResult(State
В зависимости от состояния корзины будем использовать разные представления. Для пустой корзины выведем сообщение «ваша корзина пуста». В активной корзине будет список товаров, возможность изменить количество товаров и удалить часть из них, кнопка «оформить заказ» и общая сумма покупки.
Оплаченная корзина будет выглядеть также, как и активная, но без возможности что-либо отредактировать. Этот факт можно отметить выделением интерфейса INotEmptyCartState . Таким образом мы не только избавились от нарушения принципа подстановки Лисков, но и применили принцип разделения интерфейса.
Заключение
В прикладном коде мы можем работать по интерфейсным ссылкам IAddableCartState и INotEmptyCartState , чтобы повторно использовать код, отвечающий за добавление товаров в корзину и вывод товаров в корзине. Я считаю, что pattern matching подходит для control flow в C# только когда между типами нет ничего общего. В остальных случаях работа по базовой ссылке удобнее. Аналогичный прием можно применить не только для кодирования поведения сущности, но и для .Состояние - это поведенческий паттерн проектирования, который позволяет объектам менять поведение в зависимости от своего состояния. Извне создаётся впечатление, что изменился класс объекта.
Проблема
Паттерн Состояние невозможно рассматривать в отрыве от концепции машины состояний , также известной как стейт-машина или конечный автомат .

Основная идея в том, что программа может находиться в одном из нескольких состояний, которые всё время сменяют друг друга. Набор этих состояний, а также переходов между ними, предопределён и конечен . Находясь в разных состояниях, программа может по-разному реагировать на одни и те же события, которые происходят с ней.
Такой подход можно применить и к отдельным объектам. Например, объект Документ может принимать три состояния: Черновик, Модерация или Опубликован. В каждом из этих состоянии метод опубликовать будет работать по-разному:
- Из черновика он отправит документ на модерацию.
- Из модерации - в публикацию, но при условии, что это сделал администратор.
- В опубликованном состоянии метод не будет делать ничего.

Машину состояний чаще всего реализуют с помощью множества условных операторов, if либо switch , которые проверяют текущее состояние объекта и выполняют соответствующее поведение. Наверняка вы уже реализовали хотя бы одну машину состояний в своей жизни, даже не зная об этом. Как насчёт вот такого кода, выглядит знакомо?
Class Document is field state: string // ... method publish() is switch (state) "draft": state = "moderation" break "moderation": if (currentUser.role == "admin") state = "published" break "published": // Do nothing. break // ...
Основная проблема такой машины состояний проявится в том случае, если в Документ добавить ещё десяток состояний. Каждый метод будет состоять из увесистого условного оператора, перебирающего доступные состояния. Такой код крайне сложно поддерживать. Малейшее изменение логики переходов заставит вас перепроверять работу всех методов, которые содержат условные операторы машины состояний.
Путаница и нагромождение условий особенно сильно проявляется в старых проектах. Набор возможных состояний бывает трудно предопределить заранее, поэтому они всё время добавляются в процессе эволюции программы. Из-за этого решение, которое выглядело простым и эффективным в самом начале разработки, может впоследствии стать проекцией большого макаронного монстра.
Решение
Паттерн Состояние предлагает создать отдельные классы для каждого состояния, в котором может пребывать объект, а затем вынести туда поведения, соответствующие этим состояниям.
Вместо того, чтобы хранить код всех состояний, первоначальный объект, называемый контекстом , будет содержать ссылку на один из объектов-состояний и делегировать ему работу, зависящую от состояния.

Благодаря тому, что объекты состояний будут иметь общий интерфейс, контекст сможет делегировать работу состоянию, не привязываясь к его классу. Поведение контекста можно будет изменить в любой момент, подключив к нему другой объект-состояние.
Очень важным нюансом, отличающим этот паттерн от Стратегии , является то, что и контекст, и сами конкретные состояния могут знать друг о друге и инициировать переходы от одного состояния к другому.
Аналогия из жизни
Ваш смартфон ведёт себя по-разному, в зависимости от текущего состояния:
- Когда телефон разблокирован, нажатие кнопок телефона приводит к каким-то действиям.
- Когда телефон заблокирован, нажатие кнопок приводит к экрану разблокировки.
- Когда телефон разряжен, нажатие кнопок приводит к экрану зарядки.
Структура
Контекст хранит ссылку на объект состояния и делегирует ему часть работы, зависящей от состояний. Контекст работает с этим объектом через общий интерфейс состояний. Контекст должен иметь метод для присваивания ему нового объекта-состояния.
Состояние описывает общий интерфейс для всех конкретных состояний.
Конкретные состояния реализуют поведения, связанные с определённым состоянием контекста. Иногда приходится создавать целые иерархии классов состояний, чтобы обобщить дублирующий код.
И контекст, и объекты конкретных состояний могут решать, когда и какое следующее состояние будет выбрано. Чтобы переключить состояние, нужно подать другой объект-состояние в контекст.
Псевдокод
В этом примере паттерн Состояние изменяет функциональность одних и тех же элементов управления музыкальным проигрывателем, в зависимости от того, в каком состоянии находится сейчас проигрыватель.

Пример изменение поведения проигрывателя с помощью состояний.
Объект проигрывателя содержит объект-состояние, которому и делегирует основную работу. Изменяя состояния, можно менять то, как ведут себя элементы управления проигрывателя.
// Общий интерфейс всех состояний. abstract class State is protected field player: AudioPlayer // Контекст передаёт себя в конструктор состояния, чтобы // состояние могло обращаться к его данным и методам в // будущем, если потребуется. constructor State(player) is this.player = player abstract method clickLock() abstract method clickPlay() abstract method clickNext() abstract method clickPrevious() // Конкретные состояния реализуют методы абстрактного состояния // по-своему. class LockedState extends State is // При разблокировке проигрователя с заблокированными // клавишами он может принять одно из двух состояний. method clickLock() is if (player.playing) player.changeState(new PlayingState(player)) else player.changeState(new ReadyState(player)) method clickPlay() is // Ничего не делать. method clickNext() is // Ничего не делать. method clickPrevious() is // Ничего не делать. // Конкретные состояния сами могут переводить контекст в другое // состояние. class ReadyState extends State is method clickLock() is player.changeState(new LockedState(player)) method clickPlay() is player.startPlayback() player.changeState(new PlayingState(player)) method clickNext() is player.nextSong() method clickPrevious() is player.previousSong() class PlayingState extends State is method clickLock() is player.changeState(new LockedState(player)) method clickPlay() is player.stopPlayback() player.changeState(new ReadyState(player)) method clickNext() is if (event.doubleclick) player.nextSong() else player.fastForward(5) method clickPrevious() is if (event.doubleclick) player.previous() else player.rewind(5) // Проигрыватель выступает в роли контекста. class AudioPlayer is field state: State field UI, volume, playlist, currentSong constructor AudioPlayer() is this.state = new ReadyState(this) // Контекст заставляет состояние реагировать на // пользовательский ввод вместо себя. Реакция может быть // разной, в зависимости от того, какое состояние сейчас // активно. UI = new UserInterface() UI.lockButton.onClick(this.clickLock) UI.playButton.onClick(this.clickPlay) UI.nextButton.onClick(this.clickNext) UI.prevButton.onClick(this.clickPrevious) // Другие объекты тоже должны иметь возможность заменять // состояние проигрывателя. method changeState(state: State) is this.state = state // Методы UI будут делегировать работу активному состоянию. method clickLock() is state.clickLock() method clickPlay() is state.clickPlay() method clickNext() is state.clickNext() method clickPrevious() is state.clickPrevious() // Сервисные методы контекста, вызываемые состояниями. method startPlayback() is // ... method stopPlayback() is // ... method nextSong() is // ... method previousSong() is // ... method fastForward(time) is // ... method rewind(time) is // ...
Применимость
Когда у вас есть объект, поведение которого кардинально меняется в зависимости от внутреннего состояния, причём типов состояний много, и их код часто меняется.
Паттерн предлагает выделить в собственные классы все поля и методы, связанные с определёнными состояниями. Первоначальный объект будет постоянно ссылаться на один из объектов-состояний, делегируя ему часть своей работы. Для изменения состояния в контекст достаточно будет подставить другой объект-состояние.
Когда код класса содержит множество больших, похожих друг на друга, условных операторов, которые выбирают поведения в зависимости от текущих значений полей класса.
Паттерн предлагает переместить каждую ветку такого условного оператора в собственный класс. Тут же можно поселить и все поля, связанные с данным состоянием.
Когда вы сознательно используете табличную машину состояний, построенную на условных операторах, но вынуждены мириться с дублированием кода для похожих состояний и переходов.
Паттерн Состояние позволяет реализовать иерархическую машину состояний, базирующуюся на наследовании. Вы можете отнаследовать похожие состояния от одного родительского класса и вынести туда весь дублирующий код.
Шаги реализации
Определитесь с классом, который будет играть роль контекста. Это может быть как существующий класс, в котором уже есть зависимость от состояния, так и новый класс, если код состояний размазан по нескольким классам.
Создайте общий интерфейс состояний. Он должен описывать методы, общие для всех состояний, обнаруженных в контексте. Заметьте, что не всё поведение контекста нужно переносить в состояние, а только то, которое зависит от состояний.
Для каждого фактического состояния создайте класс, реализующий интерфейс состояния. Переместите код, связанный с конкретными состояниями в нужные классы. В конце концов, все методы интерфейса состояния должны быть реализованы во всех классах состояний.
При переносе поведения из контекста вы можете столкнуться с тем, что это поведение зависит от приватных полей или методов контекста, к которым нет доступа из объекта состояния. Существует парочка способов обойти эту проблему.
Самый простой - оставить поведение внутри контекста, вызывая его из объекта состояния. С другой стороны, вы можете сделать классы состояний вложенными в класс контекста, и тогда они получат доступ ко всем приватным частям контекста. Но последний способ доступен только в некоторых языках программирования (например, Java, C#).
Создайте в контексте поле для хранения объектов-состояний, а также публичный метод для изменения значения этого поля.
Старые методы контекста, в которых находился зависимый от состояния код, замените на вызовы соответствующих методов объекта-состояния.
В зависимости от бизнес-логики, разместите код, который переключает состояние контекста либо внутри контекста, либо внутри классов конкретных состояний.
Преимущества и недостатки
- Избавляет от множества больших условных операторов машины состояний. . Оба паттерна используют композицию, чтобы менять поведение основного объекта, делегируя работу вложенным объектам-помощникам. Однако в Стратегии эти объекты не знают друг о друге и никак не связаны. В Состоянии сами конкретные состояния могут переключать контекст.
Состояние (англ. State ) - поведенческий шаблон проектирования. Используется в тех случаях, когда во время выполнения программы объект должен менять свое поведение в зависимости от своего состояния.
Назначение паттерна State
Паттерн State позволяет объекту изменять свое поведение в зависимости от внутреннего состояния. Создается впечатление, что объект изменил свой класс.
Паттерн State является объектно-ориентированной реализацией конечного автомата.
Решаемая проблема
Поведение объекта зависит от его состояния и должно изменяться во время выполнения программы. Такую схему можно реализовать, применив множество условных операторов: на основе анализа текущего состояния объекта предпринимаются определенные действия. Однако при большом числе состояний условные операторы будут разбросаны по всему коду, и такую программу будет трудно поддерживать.
Обсуждение паттерна State
Паттерн State решает указанную проблему следующим образом:
Вводит класс Context, в котором определяется интерфейс для внешнего мира.
Вводит абстрактный класс State.
Представляет различные "состояния" конечного автомата в виде подклассов State.
В классе Context имеется указатель на текущее состояние, который изменяется при изменении состояния конечного автомата.
Паттерн State не определяет, где именно определяется условие перехода в новое состояние. Существует два варианта: класс Context или подклассы State. Преимущество последнего варианта заключается в простоте добавления новых производных классов. Недостаток заключается в том, что каждый подкласс State для осуществления перехода в новое состояние должен знать о своих соседях, что вводит зависимости между подклассами.
Структура паттерна State
Класс Context определяет внешний интерфейс для клиентов и хранит внутри себя ссылку на текущее состояние объекта State. Интерфейс абстрактного базового класса State повторяет интерфейс Context за исключением одного дополнительного параметра - указателя на экземплярContext. Производные от State классы определяют поведение, специфичное для конкретного состояния. Класс "обертка" Context делегирует все полученные запросы объекту "текущее состояние", который может использовать полученный дополнительный параметр для доступа к экземпляру Context.
UML-диаграмма классов паттерна State
Пример паттерна State
Паттерн State позволяет объекту изменять свое поведение в зависимости от внутреннего состояния. Похожая картина может наблюдаться в работе торгового автомата. Автоматы могут иметь различные состояния в зависимости от наличия товаров, суммы полученных монет, возможности размена денег и т.д. После того как покупатель выбрал и оплатил товар, возможны следующие ситуации (состояния):
Выдать покупателю товар, выдавать сдачу не требуется.
Выдать покупателю товар и сдачу.
Покупатель товар не получит из-за отсутствия достаточной суммы денег.
Покупатель товар не получит из-за его отсутствия.
Реализация
Рисунок
1. Диаграмма классов паттерна Состояние.
Паттерн состоит из 3 блоков:
Widget – класс, объекты которого должны менять свое поведение в зависимости от состояния.
IState – интерфейс, который должен реализовать каждое из конкретных состояний. Через этот интерфейс объект Widget взаимодействует с состоянием, делегируя ему вызовы методов. Интерфейс должен содержать средства для обратной связи с объектом, поведение которого нужно изменить. Для этого используется событие (паттерн Publisher - Subscriber). Это необходимо для того, чтобы в процессе выполнения программы заменять объект состояния при появлении событий. Возможны случаи, когда сам Widget периодически опрашивает объект состояние на наличие перехода.
StateA … StateZ – классы конкретных состояний. Должны содержать информацию о том, при каких условиях и в какие состояния может переходить объект из текущего состояния. Например, из StateA объект может переходить в состояние StateB и StateC, а из StateB – обратно в StateA и так далее. Объект одного из них должен содержать Widget при создании.
public interface IState
event StateHandler NextState;
void SomeMethod();
public interface IWidget
void SomeMethod();
public class StateA: IState
public void SomeMethod()
Console.WriteLine("StateA.SomeMethod");
if (NextState != null)
NextState(new StateB());
public class StateB: IState
public event StateHandler NextState;
public void SomeMethod()
Console.WriteLine("StateB.SomeMethod");
if (NextState != null)
NextState(new StateA());
public delegate void StateHandler(IState state);
public class Widget: IWidget
public Widget(IState state)
OnNextState(state);
private void OnNextState(IState state)
if (state == null)
throw new ArgumentNullException("state");
if (State != state)
State.NextState += new StateHandler(OnNextState);
private IState state;
public void SomeMethod()
state.SomeMethod();
public IState State
get { return state; }
set { state = value; }
Рассмотрим пример:
IWidget widget = new Widget(new StateA());
widget.SomeMethod();
widget.SomeMethod();
При создании объекта Widget через параметр конструктора передается объект, инкапсулирующий состояние. Это состояние будет являться текущим, на его событие NextState подписывается метод OnNextState(), который заменяет state на присланный объект состояния. При вызове метода SomeMethod() в первый раз объект Widget делегирует этот вызов объекту StateA. После того, как метод StateA.SomeMethod() выполнился, объект вызовет событие NextState и передаст в параметр объект StateB, который заменяет текущее состояние StateA. При вызове SomeMethod() второй раз будет вызван StateB.SomeMethod(). То есть формально вызывается один и тот же метод, но его поведение различно.
Важно отметить, что реально в данный момент времени существует только текущий объект состояния. То есть при переходе из одного состояния в другое, предыдущий объект удаляется и на его место встает новый.