问题标签 [state-pattern]

我正在解决一个我认为最适合装饰器和状态模式的问题。高级设置类似于三明治机和分配器，我可以在其中制作一定数量的配料和几种不同类型的三明治。每个成分都有与之相关的成本。客户将使用机器选择成分来制作特定的swndwich，然后机器将分配它。

到目前为止，我已经使用装饰器模式创建了成分和不同类型的三明治：

每种成分都是这样建模的：

此外，具体成分将是：

一种特定类型的三明治可以这样建模：

所以客户会像这样创建一个特定的三明治：

作为下一步，我将创建一个 Dispenser 对象，它将充当自动机器，它预先加载了特定数量的成分（以通用单位测量），用户可以按下按钮来选择其中一个- 设置选择：

例如

• BLT：1个番茄、1个生菜、1个培根、1个面包
• SUB：1个肉丸，1个奶酪，1个意大利酱，1个面包
• ETC..

我的分配器机器将预装每种成分的固定数量的单位

• 番茄：10
• 生菜：10
• 培根：10
• ETC..

以及供用户选择特定类型三明治的按钮列表：

• 1-BLT
• 2-SUB
• 3-烧烤
• ..ETC

这个想法是跟踪成分的内部容量，并能够告诉用户，比如说，我们没有足够的培根来制作另一个 BLT

现在，我最初的想法是根据状态设计模式创建 Dispenser 对象，但是我在尝试将成分类的对象与 Dispenser 类中的某种存储组合时遇到了问题。起初，我通过名称/值对成分类型/成分数量的映射。但我不确定如何将这些模式组合在一起，以便在每次使用后自动递减。

您是否对如何继续实施这样的概念有一个大致的了解？首先，我在装饰器和状态模式的正确轨道上吗？会有更有效的方法吗？我希望我已经清楚地解释了这个问题。

感谢您的任何指导，我感谢您的任何想法

我需要帮助重构以下类，

以下是在 switch 中具有多种操作的类操作：我想避免使用 switch 语句。我读了几篇关于使用多态性和状态模式的文章。但是当我重构类时，我无法访问许多变量，属性
我是否对是否将操作用作抽象类或实现接口。
只是想知道哪种类型的重构在这种情况下会帮助
多态性或状态模式？
以及何时使用它们？

调用代码类似于：

参考主题：
链接
链接
..还有更多。

我正在尝试对某个过程进行建模，并且我认为状态模式可能是一个很好的匹配。我想得到你的反馈，但关于 State 是否适合我的需求以及它应该如何与我的持久性机制相结合。

我有一个包含许多对象的 CMS，例如 Pages。这些对象（我们将使用 Pages 的示例，但大多数对象都是如此）可以处于多种状态之一，3 个示例是： 未发布 已发布 返工

未发布时，它们是可编辑的。一旦发布，它们就不可编辑，但可以移动到 Reworking 状态。在 Reworking 状态下，它们可以再次编辑并且可以重新发布。

显然，这些页面是否可编辑的决定应该在模型本身而不是 UI 中。所以，状态模式突然出现在脑海中。但是，如何防止将值分配给对象的属性？检查每个属性设置器似乎是个坏主意：

任何想法如何工作？有没有更好的模式呢？

我在普通状态机中使用状态模式。我希望能够从 [ A -> B ]、[ B -> C ] 和 [ A -> C ] 出发。现在我们的域有一个新规则，现在我也需要从 [C -> A] 出发，但前提是我以前从未去过 B。所以我们有带有记忆的状态。有两种可能的解决方案：

1. 创建一个新的状态CB意味着C 在 B 之后，并具有这些规则 [ A -> B ]、[ B -> CB ]、[ A -> C ]、[ C -> A ]
2. 使用我们的 Context 有一个包含先前状态的列表（我们称之为 StateHistoric）和进行转换的日期（状态历史也是我们客户的域要求）的事实，然后使用这些规则 [ A -> B ]、[ B -> C ]、[ A -> C ]、[ C -> A如果B不在 Context.StateHistoric 中]。

两者中哪一个是为状态模式使用内存的更正确方法？（或这两个的另一种选择）

谢谢

我正在为 Uni 项目设计一个弹球游戏，其中应该有 2 种模式：运行模式和构建器模式，可以设计/重新设计机器的布局。

我最初的想法是状态模式——但是，我担心状态之间的公共接口可能会将它们收缩为不适合该状态的实现方法。

例如。在建造者模式下，设置保险杠或其他东西的位置是完全合适的；但是在运行模式下，它会被实现为什么都不做或抛出异常——这看起来很讨厌，尤其是如果有很多这样的方法。

有没有更好的设计呢？

我有一个涉及建模状态机的小问题。

我已经设法进行了一些知识工程并“逆向工程”了一组确定状态和状态转换的原始确定性规则。

我想知道最佳实践是什么：

• 如何严格测试我的状态和状态转换，以确保系统不会最终处于未确定状态。

• 如何强制执行状态转换要求（例如，应该不可能直接从 stateFoo 转到 StateFooBar，即向每个状态灌输关于它可以转换到的状态的“知识”。

理想情况下，我想尽可能使用干净的、基于模式的设计和模板。

不过，我确实需要从某个地方开始，我将不胜感激任何以我的方式发送的指示（不是双关语）。

一个问题，但我正在寻找两种解决方案：

• 静止的
• 动态的

静态意味着我知道所有的状态。动态意味着我不知道状态，因为最终用户可以定义它。

静态
如何创建和组织视图、视图模型和动作？我知道状态模式非常适合这种情况，但是如何从视图模型传递数据并将它们放入实体？每个动作负责一个状态？如果我对下一个状态有多个可能的选择怎么办？

我应该如何通过发布一些值来为作为字符串发送的状态选择适当的操作？

如何将正确发布的数据与实体上的特定操作相匹配（查看状态模式）？

动态
如果最终用户可以创建自己的状态怎么办？示例：应用程序有类似工作流的东西。假设我有与上面相同的情况。我没有每个州的观点，因为我不了解它们。

问题......是相同的，但我认为解决方案可能不同......但解决方案是什么？

下面是我对状态模式的实现。为了使用 NHibernate 将 State 对象保存到我的数据库中，我为每个状态类分配了一个枚举值。这存储为实体上的私有字段，并映射到我的数据库表中的整数字段。

我想知道这是否是一个好的实现，因为我将在整个应用程序中使用状态模式，并希望第一次就正确。谢谢

我正在阅读有关状态模式的信息。我才刚刚开始，所以我当然要从阅读关于它的整个Wikipedia 文章开始。

我注意到文章中的两个示例都有一些基本抽象类或 Java 接口，用于通用 State 的方法/函数。然后有一些从基础继承并以不同方式实现这些方法/功能的状态。然后是一个 Context 类，它有一个 State 类型的私有成员，并且在任何时候，它都可以等于其中一个实现的实例。该上下文类也实现了相同的方法，并将它们传递给当前状态实例，然后有一个额外的方法来改变状态（或者根据设计，我理解状态的改变可能是对已实现方法之一的反应） .

为什么这个上下文类不专门“扩展”或“实现”通用 State 基类/接口？

我有一个有许多状态的状态机A--B--C--D--E。C例如，A如果某些条件得到验证，我有很多过渡。对于每个状态，我都有一个扩展抽象类的类State，并且我有一个将每个转换方法委托给状态方法的管理器。问题是“国家可以直接调用经理转换方法吗？”。我在互联网上只看到过一个例子，其中有一个主类确切地知道转换发生了多少次（即insertQuarter(), ejectQuarter(), turnCrank(), dispense()）。我发现这样做的唯一方法是在状态中调用管理器转换方法。这是错误的做法还是不好的做法？

在此先感谢托比亚