将状态上下文作为附加方法参数嵌入状态的优缺点是什么？

Question

在设计模式 state 的上下文中。在StateContext中嵌入State作为附加方法参数的优缺点是什么？

更清楚：

public void handle(Object obj);与public void handle(StateContext context, Object obj);

将上下文重构为参数列表，而不是将其保持为类成员，将增加低耦合并增强对象的重用功能。同时，将上下文作为成员会减小参数列表的大小，也有利于具有高内聚力。

但是，当使用多个上下文实例时，具有分离的上下文会引入一类新的错误，其中可能发生全局状态不一致。

我开始考虑这个问题，因为我想到了一种切换状态的简洁方法。

Answer 1

来自四人帮书，

  

状态模式未指定哪个参与者定义状态转换的条件。如果标准是固定的，那么它们可以完全在上下文中实现。

换句话说，如果 State 实例不需要参与 State 转换，则转换逻辑可以集中在 Context 和 States 可以保持彼此分离。 （handle()方法不需要 Context 的情况就是如此。）

  

然而，让国家更加灵活和适当   子类本身指定其后继状态以及何时进行转换。这需要向Context添加一个接口，让State对象显式设置Context的当前状态。

如果 Context 将自己传递给每个 State ，则一个 State 可以明确转换通过 Context 上的回调方法到下一个。基本上， States 形成单链表。 （handle()方法需要 Context 的情况就是如此。）

  

以这种方式分散转换逻辑可以很容易地修改或   通过定义新的State子类来扩展逻辑。一个缺点   权力下放是一个国家的子类至少会有知识   另一个，介绍了实现之间的依赖关系   子类。