State设计模式

这里还是先推荐jdon中对state模式的讲解。http://www.jdon.com/designpatterns/designpattern_State.htm

那就先对banq老师的状态模式做个分析，正如他在文章中提到的如何使用状态模式：

1.状态管理员（StateManager）:用于控制各种状态之间的切换；

2.已经实现了一个统一父类的各种状态。

这是banq老师的观点。

我要写点自己的理解：

state模式主要是为解决我们很多程序中if--else过多的分支引起的混乱。这个方面咱太有体会了，刚刚进入公司项目组时，也因为是新手的缘故，对那么多的if-else转换真是抓狂了。硬着头皮啃逻辑，还好没有太多的swith，要是那样就更让人发疯了。要先看看都有哪些转换状态，在switch中是如何进行分支的，想想都恐怖，关键是这个项目的元老级同事也是实验编程的，毅力和决心绝对令我佩服不已，但是某些程序段绝对让我抓狂不已（元老当初也算是新手吧，比起当时的我是强的多了！但是现在的他们依然让我佩服！他们的研究能力是我极为羡慕的！也算是我的入门师傅啦！在此谢过！尽管有些许抱怨切莫见怪！题外话到此over！）。看过thinking in  java，但是当初实在是新手中的新手（现在是新手中的老手了，终于晋点级了！呵呵），里面有些好的实践，但是也不是很理解，代码还是乱。不管怎样是到了重构的关键时期了，否则项目对市场的影响会动摇公司的竞争力的。不管是抱怨，还是什么，到此结束啦！

 

在jdon中，banq老师对状态模式的分析（有个帖子里面说的更详细些），我不在此赘述，仅发表个人见解：

如前所述，状态模式需要一个状态管理器，还有包含所有子状态业务方法的父类。

我可以对这句话有更深入的分析：这个状态管理器，最重要的是要管理当前状态，但是它不必知道这个状态是什么，个人觉得这个功能必须要有，在jdon的演示代码（看本文最开始的jdon链接）中，状态管理器是用context来表示的，它有个私有属性state，通过这种方式来获取当前模式。

然后最令我质疑的不是对当前状态的管理，而是，对于不同的状态，可能有不同的操作，如果按照这些前辈的方式的话，这个状态管理器就要知道当前状态，也就是会跟当前状态进行耦合，以达到能够对不同的状态调用不同方法的目的，个人觉得这样的状态模式不可取。使用状态模式的目的就是降低复杂度（只是针对业务和框架的复杂度，但或许我们会因为某些复杂逻辑多写几行代码！），降低不同管理区域之间的耦合，提高模块管理的内聚。

所以，个人的看法是：

1.应该有一个状态管理器。

   这个管理器管理当前状态，这个状态，如同在jdon state模式context类中展现的应该是父类的一个引用，即State类。

   并且要有一个状态变化监听器，监听当前状态是否发生变化。如果有变化，就调用新状态的业务方法。

2.State类的方法限定。

    状态父类应该有两种形式：

        1）各个子状态下，要执行的操作接口都是相同的。在这种情况下，StateManager无需关心任何状态实现，只需要按部就班的进行统一方法调用即可。

        2）各个子状态下，要进行不同的操作。在这种情况下，个人觉得应该模仿前一种方式，淡化其具体方法实现，甚至可以借鉴Command模式（可以看本博客中对Command模式的说明），规定统一接口，在各个子状态中调用统一方法接口。

 

个人觉得要是以上两大点能够满足的话，我们就可以提高框架的可扩展性。

还有一点质疑，可能这点疑问写到jdon论坛里更好，还可以得到banq前辈的指点，所以不管是否正确，总是提出来供大家一起把玩思考比较好。在jdon中，banq前辈点出，我们在使用状态模式前要先了解各种状态，当然我看到的资料里的示例代码也是这样干的，但是我还是觉得，如果我们的父状态类（在此是State抽象类）里要包含我们知道的所有状态（专指状态业务）的话，对我们以后的扩展是否方便呢？还有，我们各个子状态间需要相互知道吗？尤其是前一个状态要知道后一个状态这种情况，本人才疏学浅但还是觉得那么做对代码的扩展性有妨害之处，我们风扇上的旋钮那几个档相互之间应该是独立的吧？3档要知道他的下一档是4档吗？状态模式的介入，不能比if-else模式更复杂，否则也会失去扩展性的。愚见啊！

 

附：本文仍系抛砖引玉系列State模式篇，希望同行们给点意见，切莫而言打击啊，兄弟姊妹们也知道，干这行真不容易啊！