Каковы плюсы и минусы встраивания контекста состояния в качестве дополнительного аргумента метода в состояние?

В контексте шаблона проектирования состояние. Каковы плюсы и минусы встраивания StateContext в качестве дополнительного аргумента метода в State?

Чтобы было понятнее:

public void handle(Object obj); vs. public void handle(StateContext context, Object obj);

Рефакторинг контекста в список параметров вместо сохранения его в качестве члена класса увеличил бы низкую связанность и расширил бы возможности повторного использования объекта. В то же время наличие контекста в качестве члена уменьшит размер списка параметров, а также выиграет от высокой связности.

Но наличие несвязанного контекста вводит новый класс ошибок, где могут возникать несоответствия глобального состояния при использовании нескольких экземпляров контекста.

Я начал думать об этой проблеме, когда думал о чистом способе переключения состояний.


design-patterns state-pattern
person mike    schedule 11.04.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Из книги «Банда четырех».

В шаблоне состояния не указано, какой участник определяет критерии перехода состояний. Если критерии фиксированы, то их можно полностью реализовать в контексте.

Другими словами, если экземплярам State не нужно участвовать в переходах State, логика перехода может быть централизована в Context и < em>States могут оставаться несвязанными друг с другом. (Это тот случай, когда методу handle() не нужен Context.)

Однако, как правило, более гибко и уместно позволить подклассам State самим определять свое состояние-преемник и время выполнения перехода. Это требует добавления интерфейса к Context, который позволяет объектам State явно устанавливать текущее состояние Context.

Если Context передает себя каждому State, один State может явно перейти к следующему с помощью метода обратного вызова в Context. По сути, States образуют односвязный список. (Это тот случай, когда для метода handle() требуется Context.)

Децентрализация логики перехода таким образом упрощает изменение или расширение логики путем определения новых подклассов State. Недостатком децентрализации является то, что один подкласс State будет знать по крайней мере один другой, что вводит зависимости реализации между подклассами.

person jaco0646    schedule 12.04.2016
comment
если экземплярам состояния не нужно участвовать в переходах между состояниями, логика перехода может быть централизована в контексте, т. е. если состояния и их переходы могут быть смоделированы как DFA. Спс, не подумал об этом. - person mike; 12.04.2016