学习设计模式之State

模式不是万能的
难道为了少写几个ifelse就要用state模式吗
我觉得state模式不过是把if -else语句换成了一个单独的类吧了

当然，维护起来是方便些，不过类大量增加也让人烦

我到有个解决办法。。。。。。。。。。

珍爱生命，远离JAVA  ：）

大部分情况下不需要用到模式，我个人现在倾向于xp和重构那一套知识。
但很多时候用模式能够很好的解决问题。比如有30多个if else，里面有n多逻辑和接口调用。我不信一个正常的人能在短时间内明白里面的意思。

而state模式，本身的目的也不是为了替换if-else。。。如果把它理解为简单的替换。。方向就错了。。。
state的理念我认为是状态转换。也就是从某种状态转换为另外一种状态，或者有一套自己的转换过程，比如a->b->c状态，他们内部自己去管理这个状态具体是用哪一个流程来转换。类似一个复杂的开关控制面板系统。或者红绿灯。

我在刚开始读很多模式书的时候也会这样，不过后来就变了，有本书改变了我的看法，就是<<refactoring to pattern.>>
读过以后我感觉现在更“深入”了些，也会在开始想到可能用到哪些模式，但开始却不去用了。。。。

个人感觉从你的代码看起来你这应该是vistor pattern，而不是什么state pattern.
vistor pattern : 当新定义一个handler操作时，并不需要更改Context的结构。
而对于state pattern来说，当状态改变时，应该有state自己改变自己的行为而不是由一个handler来改变。

Factroy.getHandler(context.getState());
里面还不是一样要写 if else?

格外认真的看完之后，发现没什么用！

楼主明显写错了。
state模式的意图就是通过state的多态来消除判断状态的分支，以楼主这个例子，实现类应该是stateFirst,stateSecond,覆盖的父类方法是printImpl:stateFirst.printImpl(){ this.print("printImplFirst: " + this.toString())}等等。
在实现类里再有类似这样的语句  if(state != null && state.equals("first")) 实在是很搞笑的事情。
另外例子也不恰当，state模式一般应用的场景还应该包括各个状态之间的转换，比如业务的状态从stateFirst在excute之后将转换为stateSecond，否则直接用多态就可以了，没必要再维护一个context

状态的转换,就不说了,前面已经讨论过了.

你说的利用state的多态是状态模式消除分支的思想,
昨天看了下GoFBook总算明白了, 这个例子确实有问题....
应该不存在state--> StateHandler 而是State是个抽象类, 然后对应每一个State的子类, 有handle方法...
当然这是GoF给出的标准实现方法...但不是我想表达的思想,
我以后把这个例子重构下吧

这个不就是用了抽象类和接口吗？state设计模式，貌似很多模式都用到了，寒。。。。

最常见的就是dao，比如写一个basedao，然后oracledao、msdao。。都继承basedao，在弄个daofactory来生成dao，然后要新增dao的时候只需再加一个继承basedao的类就可以