问题标签 [state-pattern]

我将要构建的软件将涉及很多不同状态之间的“应用程序”切换。可以完成的某些任务取决于应用程序所处的状态。我正在考虑使用枚举作为状态

但是后来我想在数据库中使用查找表可能会很好，因为状态确实会经常更新/重新排序

就我而言，我需要做类似的事情

我认为使用枚举更容易实现上述情况。但是，当涉及到更新状态排序顺序或描述时，它会非常困难。

我应该使用反射根据查找表中的值动态创建枚举吗？或者我应该使用状态模式？我看到枚举相关的问题是性能影响。而状态模式会产生大量的冗余代码。

你怎么看？提前致谢！

我有一个 Order 类，它经历了一系列定义的状态。为了解决这个问题，我实现了 State 模式，使得 Order 对象有一个 CurrentState 成员，该成员实现了 IOrderState 接口。然后我有这个接口的具体实现，例如 OrderStateNew、OrderStateDelivered 等

我的问题是，在状态之间转换 Order 对象的正确方法是什么？有一个允许外部服务设置状态的 Order.SetState() 方法是否可以接受？确定状态更改的标准存储在 Order 对象的外部，因此这似乎是显而易见的答案，但我对在我的对象上使用公共方法来更改像这样基本的东西有点不安。

附加说明 我认为添加更多关于我的实现的细节可能会很有用，因为我想知道我是否首先正确地使用了该模式。这是用于创建和授权订单的公共 API

OrderFacade.Authorise() 函数看起来像这样

如您所见，CurrentState 成员是当前 IOrderState 实现，它确定哪些活动对对象有效。我想知道这是否应该负责确定过渡而不是 OrderFacade？

我有一个画了很多东西的面板。为了提高绘图效率，我使用了 BufferedImage，这样我就不必在每次发生某些事情时都绘制所有内容。

我的paintComponent 只需要'if' 语句：

我喜欢使用状态模式的想法，但我不确定使用它的正确时机？我不喜欢必须为 extraOnly 设置布尔值的想法，也许我也有模式发烧 :)。每个状态只有一个方法，draw(Graphics g)

由于这是我的应用程序在 MVC 模式中的视图部分，我也不确定使用状态模式是错误的。状态不应该是模型而不是视图的一部分吗？

我必须用 java SAX 解析器解析一些 xml。趁着忙，看到这里可以使用状态模式。

定义了清晰的状态和状态转换，类似于 xml 文档的结构。

要实现状态模式，我必须定义一个接口（或抽象类）。最明显的接口方法是：

但是我遇到的问题是如何返回信息。我需要一个结构中的 xml 文档中多个级别的信息。

这是 xml 文档的一部分

我的假设是否正确，即状态模式适合这里？如果是这样，在这里实施它的最佳方法是什么？

iPhone 应用程序中的状态模式——在我的例子中，是一个相对轻量级的实用程序应用程序——是否使用太多内存？

据我了解，状态模式使用了几个类；这些类代表不同的状态。所有不同的状态对象都被实例化并存储在不同的指针变量中，直到需要状态，此时将其设置为curState对象。

我认为我可以延迟加载每个状态对象以节省一些内存和加载时间；如果我的应用收到内存警告，我就可以释放这些对象。

但我想知道的是，这种模式在 iPhone OS 应用程序中的一般用途是否占用了太多内存？iPhone 开发者应该远离这种模式吗？是否有更适合 iPhone OS 的不同模式？

我对状态模式的以下实现有一些疑问：

我有一个 Order 对象。为简单起见，假设它有数量、productId、价格和供应商。此外，还有一组已知状态可以转换顺序：

• 状态 a：订单是新的，数量必须 > 0 并且必须有 productId。价格和供应商尚未指定。
• 状态b：有人检查订单。只能取消，或指定供应商。
• 状态c：供应商只能填写要向客户收取的价格。
• 状态d：订单被取消。

1. Order.isValid() 状态之间的变化。即，在状态 a 中某些操作无法完成。因此，它们看起来像：
   void setQuantity(int q) {
   if (_state.canChangeQuantity()) this.quantity = q;
   否则抛出异常。
   这是对的，还是我应该让每个状态都实现setQuantity
   操作？在这种情况下，值将存储在哪里？在顺序还是状态？在后一种情况下，我将不得不在每个状态转换中复制数据？

2. orderProcessor.process(order) 是一个检查 order.IsValid 的对象，将订单转换为某种状态，将其保存到数据库并执行一些自定义操作（在某些状态下，通知管理员，在其他状态下通知客户端等）。每个州我都有一个。
   在 StateAOrderProcessor 中，检查订单的人会通过电子邮件收到通知，并且订单会转换到状态 b。
   现在，这将状态转换推到了 Order 类之外。这意味着 Order 有一个“setState”方法，因此每个处理器都可以更改它。从外部改变状态的这个东西听起来不太好。那正确吗？

3. 另一种选择是将所有验证逻辑移动到每个状态的处理器，但现在我必须跟踪订单数量何时更改，以查看该操作在当前状态下是否有效。 这让我觉得订单有点乏味。

你们觉得怎么样？你能给我一些建议来更好地设计这个东西吗？

“架构模式表达了软件系统的基本结构组织模式”。

有些软件系统可以描述为有限状态机（特别是许多实时系统和嵌入式系统），如果我们考虑前面第一段中对“架构模式”的描述，你不认为在具体案例“状态设计模式”也可以是“架构模式”吗？

在与一位初级开发人员讨论涉及“状态设计模式”的设计文档时，我收到了这个问题。我对这个问题的回答是肯定的，“状态设计模式”可以被认为是“架构设计模式”，因为应用程序主要是一个有限状态机。无论如何，在谷歌中我没有找到与这个问题相关的具体讨论，所以我不确定我的答案是否正确。

正确答案是什么（如果可以给出）？你回答的理由是什么？

最好的祝福。

我在 java 中有一个使用经典状态设计模式的工作解决方案，并且在将其转换为 ruby​​ 时遇到了一些困难。我是 ruby​​ 新手，但我认为困难在于如何在动态语言中实现模式的差异。

我的界面描述了模型在每个状态下可以执行的操作：

接下来，我实现状态接口并创建我的逻辑的具体状态：

如您所见，每个具体状态都可以进入模型并更改其状态。为了避免封装问题，我在 Model 类中实例化了我的具体状态，它还引用了当前状态：

客户会像这样使用模型：

我认为上述所有 Java 都很简单，但现在我正试图将这种设计移植到 Ruby 中。我知道类型检查的差异，以及模块和 mixin 在 Ruby 中与 Java 接口相比应该如何工作。

我还在镐书中找到了关于 Ruby 中的状态设计模式的信息。现在我有点困惑哪种是尝试这种转换的最佳方法。我仍然在 Java 盒子里思考，想知道我是否应该在不同的 .rb 文件中实现每个状态的具体实现，然后在客户端类中需要它？

有没有办法在不使用 delegate.rb 库的情况下实现上述功能？

任何有关如何开始我的转换的建议都将受到热烈欢迎。

概述：

我正在尝试改进我使用状态模式的程序的设计。我将发布问题的简要描述，当前设计的类图/描述的图像，然后是相关类的标头代码。

问题：

我正在为程序使用状态模式的变体。在这个变体中，我有一个“控制器”，它利用了两个抽象类，“状态”和“事件”，这两个抽象类都扩展了几个具体类型。这两个抽象类用于对因事件类型和当前状态而异的“事件”进行响应。每个状态都有一个“处理程序”函数，该函数被重载以获取每个具体事件类型。

“控制器”包含一个“事件”类型（抽象类）的队列，其中包含已发生的“事件”（具体类）列表。控制器一次“处理”每个事件，方法是从队列中检索它，并将其传递给该特定类型事件的状态处理程序。

问题是为了获得正确的类型以将事件传递给状态的适当处理程序，我必须将事件向下转换为正确的具体类型。目前，我通过向“状态”类 (getType()) 添加一个方法来实现这一点，该方法由每个具体事件类型实现，并返回一个表示该事件类型的整数。然而，这种做法非常“不优雅”，并导致使用枚举来驱动“切换”块和“向下转换”——这不是很好的设计做法。

如何更改此设计以使事件传递到状态更优雅？

类图

标题代码

策略设计模式和状态设计模式有什么区别？我在网上浏览了很多文章，但无法清楚地看出区别。

有人可以解释一下外行术语的区别吗？