C#-设计模式-状态模式

1.定义

很多时候，我们的程序可能又许多状态（比如页面上的功能就有增删改查四种状态），每种状态要执行的操作可能不一样，一般情况下，我们会使用if判断状态，然后在代码块中执行适当的代码，但是一旦业务逻辑很复杂的时候，这样做就很难维护。

状态模式其实和策略模式很类似，

策略模式是将会经常改变的算法抽象出来，通过不同的实现类来达到更换算法的功能。

而状态模式呢，经常会改变的是状态，我们就需要将状态和对应的行为抽象出来，方便状态的改变。

2.代码实现

public interface State
{
    void DealHttpRequest();
}

public class AddState : State
{
    public void DealHttpRequest()
    {
        throw new NotImplementedException();
    }
}

public class DelState : State
{
    public void DealHttpRequest()
    {
        throw new NotImplementedException();
    }
}

public class UpdateState : State
{
    public void DealHttpRequest()
    {
        throw new NotImplementedException();
    }
}

上面的代码和策略模式很像，都是将变化的部分进行抽象。

调用的时候，这样：

public void Main()
{
    IHttpContextAccessor _contextAccessor = new HttpContextAccessor();
    var QueryCollection = _contextAccessor.HttpContext.Request.Query;
    var stateStr = QueryCollection["state"].ToString();
    var state = GetState(stateStr);
    state.DealHttpRequest();
}

private State GetState(string state)
{
    switch (state)
    {
        case "add":
            return new AddState();
        case "del":
            return new DelState();
        case "update":
            return new UpdateState();
        default:
            return null;
    }
}

通过判断状态的不同，然后做出不同的动作。当有新状态的时候，我们需要对接口提供一个新的实现，并且还需要修改GetState方法。

这里虽然还是对原有方法进行了修改，但是这也是没有办法的事情。

3.特点

优点：将和状态绑定的变化进行抽象封装，当遇到新的状态时只需要将修改状态工厂，并实现一个新的状态类即可。

缺点：可能会引入很多状态类（有时候设计成内部类挺好的）

策略模式和状态模式的区别：其实这两个模式实现起来是很像的，都是对变化进行抽象，区别我个人觉得是，策略模式关注点在于策略的变化，这种变化是需要替换原有的实现。

但是状态模式不是，状态模式是多种实现在程序运行中都有可能遇到。

也就是说策略模式在程序中选择一种策略进行使用，但还是状态模式所有的状态都会使用。

4.一点想法

我个人觉得状态模式就是将状态和他的行为抽象出来，还是需要使用if或者switch来判断到底是那一种状态，而且这种状态多的时候，if和switch的长度也会很长。

我看到过一种另类的实现方法，链接

这种模式将if判断也进行了分割，将状态的判断也放在状态类内部进行，实现出的结果我觉得很惊喜，但是个人还是觉得这里的逻辑和引用方式过于繁琐，如果是没有深入学习过该模式的人恐怕很难理解。

因此不在这里再说了（说实话，使用该方法写的例子至今跑不对，尴尬）