问题标签 [state-pattern]

这是一个关于将输入键映射到实现状态模式的类中的动作的最佳策略的编程风格问题。

我正在处理两个类：

第一个实现状态模式，它控制多状态物理设备：

第二个是 KeyListener，它检索所有键盘输入并在按下的输入键与（暂时）硬编码绑定表匹配时从设备控制器调用适当的操作：

是否有最佳实践编码风格将键绑定到控制器中的操作？我是否必须像示例代码中那样通过 switch 语句？在我看来，这个解决方案有点脏代码：状态模式不是应该消除不可维护的 if 和 switch 控制结构吗？

谢谢你的建议。

我正在通过阅读Head First Design Patterns来学习设计模式，并且我刚刚完成了关于状态模式的章节。但是，有一件事我没有得到：

在书中，有状态的类称为Context，而实际的状态实现State接口。当给书一个请求时，使用这里的方法来改变状态：

1. Context接收请求；
2. Context 在它拥有的 State 上调用 handle() 方法，将请求交给 State；
3. State 处理请求，并在 Context 中设置 State 如果它应该改变。为此，States 将 Context 作为一个字段。

但是，在我看来，这似乎在两个类之间给出了某种“递归”耦合，并且是不直观的。如果我没有阅读他们的解决方案，我更喜欢以下设计：

1. Context接收请求；
2. Context 在它拥有的 State 上调用 handle() 方法，将请求交给 State；
3. State 处理请求，并返回一个 State；是否是另一个国家取决于如何处理请求。
4. 上下文将自己的状态设置为返回的状态。

我能想到的优点和缺点：

1. 如果我们将所有可能变化的东西放入 State 类、Context 和 State 中并变得更加解耦，因为它们不需要窥视彼此的字段；
2. State 类可能会变得更大；
3. 状态可能不容易在不同的上下文中重用。但是，我们可以将States 实现为实现State 接口的抽象类，并具有由抽象States 子类化的Contexts 使用的具体States。

是否有任何具体原因应该支持第一个（由Head First Design Patterns使用），或者第二个选择也有效并在实践中使用，或者它有一些我没有看到的严重缺陷？

感谢您的所有投入以及您花时间阅读和回复！

我正在尝试使用 Entity Framwork 4.1、Code First 和 Fluent API 映射实体。我的场景是我正在使用抽象类实现状态模式。查看我的实现：

//我的合约

现在，我当前的 SaleStatus 映射：

当我运行我的项目时，我收到了这条消息：

指定的架构无效。错误：(107,6)：错误 0075：关键部分：SaleStatus 类型的“IdSaleStatus”无效。密钥的所有部分都必须不可为空。

任何人都可以帮助我吗？

谢谢，

此致。

米歇尔·马加良斯

我目前正在从事的项目有很多问题。该项目已有 10 多年的历史，它基于 90 年代非常流行的商业 C++ 框架之一。问题在于状态图。该框架提供了相当常见的状态模式实现。每个状态都是一个单独的类，具有进入动作、状态动作等。有一个开关根据接收到的事件设置当前状态。

魔鬼隐藏在细节中。那个项目是巨大的。大约2000 KLOC。肯定有太多的状态图（我见过使用状态图实现的“for”循环）。更重要的是......框架允许将状态图嵌入到另一个状态图中，因此有许多状态图具有七个甚至更多级别的嵌套。因为状态图在不同的线程中运行，并且可以在状态图之间发送事件，所以我们有很多同步问题（以及接口中的大混乱）。

我必须承认这个问题的规模是巨大的，我不知道如何去解决它。我的第一个想法是尽可能多地从状态图中删除代码并将其放入单独的类中。然后从状态图中委派这些类来完成工作。但结果我们将有许多单独的函数，它们在逻辑上没有任何特定的功能，并且状态图架构的任何更改也需要更改这些类和函数。

所以我寻求帮助：你知道任何可以帮助我解决这个问题的书籍/文章/魔法文物吗？我想至少在不引入任何隐藏依赖项的情况下将尽可能多的代码从状态图中分离出来，并保持分离的代码可维护、可测试和可重用。

如果您对如何处理此问题有任何建议，请告诉我。

我的申请中有一个注册页面。它有 3 个状态和 1 个错误状态（如果出现任何错误）：

1. 填写基本信息
2. 选择套餐
3. 说谢谢
4. 错误

现在我想在这里使用状态模式。首先，我创建了一个可以的控制台应用程序。现在我想在我的 MVC 应用程序中实现这个逻辑，但我对结构感到困惑。我的意思是我需要多少视图、模型和控制器，以及在哪里放置我的逻辑。

假设我有一个Order班级，它可以处于三种不同的状态CheckedState：PaidState和OrderedState。

状态机将使用标准状态设计模式 (Gof) 实现。

您通常如何对此进行单元测试？您是否为每个状态类（CheckStateFixture, , ...）使用一个夹具，并为上下文类使用PaidFixture另一个（ ）？OrderFixture或者您是否只使用一个用于Order放置所有单元测试的上下文类 ( ) 夹具？

我是 C# 中状态模式实现的新手，您能否提供一些有关如何实现它的信息。

我正在使用状态模式在 C# 中重构状态机。目前我的状态机包含 5 个状态，只能通过状态前进或后退，即从状态 1 到状态 2、3 和 4 最终到达状态 5。

我能够继续前进

每次您想前进时都会创建一个新状态，但是，一旦所有这些都已创建和/或您想后退，我将需要进入相同的状态，而不仅仅是一个新状态。我怎样才能做到这一点？有没有更好的方法让它变得简单？

我有一个对象层次结构，它们都具有相似的行为。我想将行为与 POCO 定义分开。由于行为代表将对象移动到各种状态，因此在我看来，这就像状态模式的工作。但是，它并不像每个函数只有一个定义那么简单，因为每个对象的行为可能略有不同。

例如，假设我有以下基于抽象基类的类：

层次结构表示不同类型的对象。假设所有对象都遵循相同的基本工作流程：提交、批准、执行、关闭。

现在，每个函数的行为也是分层的，这意味着在 Class1 上调用函数 Approve() 应该与调用从 BaseClass 继承的行为相同，但 Class2 将覆盖 Approve() 函数，因为该类型遵循不同的批准过程。

我在尝试将状态模式应用于这些对象时迷失了方向。我可以选择将函数放在对象本身上并以这种方式继承它们，效果很好，但它破坏了 POCO 设计。我还可以为每个对象类型使用 switch 语句来实现 Approve() 函数，但这会破坏我的多态设计。

如何将状态模式应用于多层多态对象定义并与设计原则保持一致。

更新：让我澄清一下，我认为除了作用于对象之外做其他事情的功能不属于 POCO。例如：Approve 函数将发送电子邮件并触发其他系统中的事件，而不仅仅是修改对象的状态。也许这只是我。

对于我正在实施的特定状态模式，我不确定最佳 OO 设计方法应该是什么。请考虑以下几点：

我犹豫的领域是这里这个词的用法new，即。new SomeState()用另一个 State 或new SomeRequest()在 theController或 another中实例化 a State。在我看来，这会在 States 和它们的兄弟姐妹以及 theController和States 之间产生高度耦合。

要求如下：

1. 必须可以添加新状态，例如添加SniffingState.

2. 还必须可以用新的国家取代现有的国家。例如，我应该能够OffLeachState用OffLeashState执行不同操作的不同替换。例如（由于某种原因，代码不会格式化）：

   public class OffLeachState2 extends DogState {
   public void seeCat(Cat cat) {
   if (dog.knows(cat)) {
   // 狗更改为 "PlayWithCatState"
   // 猫收到 "PlayWithDog" 请求
   } else {
   // 狗更改为 " ChaseAnimalState"
   }
   }
   }

3. World最后，必须记录类中的所有更改。这意味着 World 类有一个记录器，可以跟踪正在发生的一切。这也是因为 World 类是一个模型，并且必须触发 anotifyObservers()以便视图知道要做什么。

我的问题是，状态、请求等应该存储在哪里？例如：

1. 应该有状态“吸气剂”Dog吗？例如dog.getBarkingState()，，，dog.getOnLeashState()等？这似乎是有道理的，但它不会使Dog班级抵制改变。即，每次我添加一个新DogState类时，我还必须确保它Dog有一个吸气剂。此外，他们World不知道这些更改，因此它不会记录它们，也不会通知观察者。

2. 应该有一个班级叫DogStates我可以跑DogStates.getBarkingState()吗？再次，与上述类似的问题。

3. 他们应该成为World班级的一部分吗？例如，world.setDogState(dog, world.getDogBarkingState()？这将解决日志记录/更新问题，但会给班级带来太多责任World。

4. 例如，它应该是它们的某种组合world.setState(dog, dog.getBarkingState()吗？这可能很好，但不能保证类型安全。例如，我可以传入一个Dog带有 a 的对象CatState，它不会知道其中的区别。

解决方案#4 对我来说似乎是最好的，但我想对这个问题提出一些其他意见。

同样的问题也适用于Request对象。我最初想Request通过与对象关联的字符串发送 s，例如world.sendRequest(dog, DogRequests.SEE_CAT)，但后来我无法将 cat 对象作为参数传递。

非常感谢您的宝贵时间！

这变得有点棘手。我在我的应用程序中使用状态模式来管理状态。我想在我的应用程序中拥有每个状态的单个实例，但我不想将每个状态类都设为单例类。我想到的另一种方法是编写 StateLocator 类。StateLocator 可以是单例的，它可以保存所有状态的实例。请指导我 StateLocator 是否看起来是一个好的解决方案，或者是否有任何其他解决方案我仍然能够只有一个状态实例并且可以避免单例。

任何帮助表示赞赏。例如