状态模式可以帮助只读状态吗？

Question

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

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

未发布时，它们是可编辑的。一旦发布，它们就不可编辑，但可以进入返工状态。在返工状态下，它们可以再次编辑并且可以重新发布。

显然，这些页面是否可编辑的决定应该由模型本身而不是 UI 决定。于是，State 模式就出现在我的脑海中。但是，如何防止为对象的属性赋值？检查每个属性设置器似乎是一个坏主意：

if (!CurrentState.ReadOnly)

有什么想法如何工作吗？有更好的模式吗？

Answer 1

使用维基百科的 Java 示例，该结构有一个 Context，它调用在基础中定义的方法状态，具体状态会覆盖该状态。

在您的情况下，上下文是一些东西就像一页。在某些状态下，edit() 方法只是一个无操作。上下文上的某些操作可能会隐式执行状态更改。客户端代码中永远不需要测试您所处的状态。

Answer 2

更新：

今天早上我实际上想到了一种方法，该方法可以适用于您的具体情况并且更容易维护。我将在这里保留原来的两点，但我将推荐最终选项，因此请跳到“更好的方法”部分。

1. 创建一个 ThrowIfReadOnly 方法，该方法按照其说明执行操作。这稍微减少了重复性并避免了嵌套。

2. 使用接口。有一个实现所需功能的 IPage，让每个公共方法返回一个 IPage，然后有两个实现，一个 EditablePage 和一个 只读页面。每当有人尝试修改ReadOnlyPage时，它就会抛出异常。还要在 IPage 接口上放置一个 IsReadOnly 属性（或 State 属性），以便消费者可以实际检查状态，而不必捕获异常。< /p>

选项 (2) 或多或少是 IList 和 ReadOnlyCollection 协同工作的方式。它为您省去了在每个方法开始时进行检查的麻烦（从而消除了忘记验证的风险），但要求您维护两个类。

--更好的方法--

正确的技术规范将有助于澄清这个问题。我们这里真正拥有的是：

• 一系列任意“写入”操作；
• 每个操作都有相同结果，具体取决于状态：
• 要么采取操作（未发布/返工），要么失败/无操作（只读）。

真正需要抽象的并不是动作本身，而是所述动作的执行。因此，一点点功能性的优点将在这里帮助我们：

public enum PublishingState
{
    Unpublished,
    Published,
    Reworking
}

public delegate void Action();

public class PublishingStateMachine
{
    public PublishingState State { get; set; }

    public PublishingStateMachine(PublishingState initialState)
    {
        State = initialState;
    }

    public void Write(Action action)
    {
        switch (State)
        {
            case PublishingState.Unpublished:
            case PublishingState.Reworking:
                action();
                break;
            default:
                throw new InvalidOperationException("The operation is invalid " +
                    "because the object is in a read-only state.");
        }
    }
}

现在编写类本身几乎变得微不足道：

public class Page
{
    private PublishingStateMachine sm = new
        PublishingStateMachine(PublishingState.Unpublished);

    private string title;
    private string category;

    // Snip other methods/properties
    // ...

    public string Title
    {
        get { return title; }
        set { sm.Write(() => title = value; }
    }

    public string Category
    {
        get { return category; }
        set { sm.Write(() => category = value; }
    }

    public PublishingState State
    {
        get { return sm.State; }
        set { sm.State = value; }
    }
}

这不仅或多或少地实现了状态模式，而且您不需要维护单独的类，甚至不需要维护单独的类。不同状态的单独代码路径。例如，如果您想将 InvalidOperationException 转换为无操作，只需从 Write 方法中删除 throw 语句即可。或者，如果您想添加其他状态，例如 Reviewing 或类似的状态，您只需添加一个 case 行。

这不会为您处理状态转换，也不会处理任何根据状态执行不同操作的真正复杂的操作（除了“成功”或“失败”之外），但听起来您并不需要这样做。因此，这为您提供了一个几乎不需要使用额外代码的嵌入式状态实现。

当然，仍然可以选择依赖注入/AOP，但显然这种方法会带来很多开销，而且我可能不会将它用于如此简单的事情。