图1：策略模式类图
图2：状态模式类图
熟悉uml类图的朋友，可以看出，策略模式的类图和状态模式的类图实现是很相似的，这也是为什么设计模式中，我们把这两种模式比喻成为孪生兄弟，很多时候，我们在运用上述模式来解决实际问题的时候，也经常混淆他们，其实，个人倒是认为，就算大家用法不同其实也没有必要介意，因为设计模式的应用是紧贴着设计原则来走的，不论是状态模式，还是策略模式，我们都是紧紧的遵守着开闭原则，里氏代换原则，和迪米特原则，充分的面向接口编程，利用封装特性；策略模式主要是考虑到当我们要增加新的算法策略的时候，如何能在最小代价下面实现增加，最典型的应用就是莫过于在超市商场的“多样的”打折算法下面，
商场有很多中商品的计算规则，比如说vip会员，白金会员，普通会员，非会员，买多少送多少，节假日打折，今天打五折，明天打八折，如果我们采用传统的做法，我们那么会一个足够长的if-else语句要判断所采用的算法规则计算价钱，买你对应用需求变化如此频繁的应用，我们首先应该想到的是设计模式的开闭原则，对修改关闭，对扩展开放，如果采用平时的写法，那么我们每次都要修改冗长的if-else判断，而采用策略模式以后，我们只要增加新的算法类，然后选择新的算法即可；
策略模式：他定义了算法家族，分别封装起来，让他们之间可以相互转换，次模式让算法的变化，不会影响到计算算法的客服；
我们看下gof的策略模式的定义，因为我们的算法是面向的算法接口编程，那么通过里氏代换原则，我们之间的算法体现了上面文字的相互转换，至于封装，是因为我们把算法接口放在了一个名字叫做statery_context的类里面包装起来了，并且通过一个同一的接口像外开放了算法的功能实现，至于初始化那个算法实例，这是context的事情，而不是在于算法调用的客服端来修改的；
下面，我们来看下状态模式；
状态模式的类图和策略模式的类图很相似，都是面向一个接口有一系列不同的实现，然后调用的时候面向接口调用不同的实现；但是，策略模式和状态模式虽然类图上很相似，但是运用的时候，个人觉得有很大的区别，关键在于你在如何理解你的代码需求和设计要求，状态模式在gof的定义如下：
当一个状态的内部状态改变时允许改变其行为，这个对象看起来改变了其类；
状态模式主要突出了两个字:”改变”，对！对象的状态决定了状态的行为，事物的本质决定了事物的行为，我们精神亢奋的时候，我们拼命的工作，我们拼命的工作就导致了我们身心疲惫，物品们身心疲惫就导致我们的行为是需要休息；从这里我们可以看出，事物的内在状态决定了事物所做出的行为，而事物的行为势必又会改变我们事物的状态，两者在不断的相互影响，然后实现状态的迁移和跃迁；
从这两点，我们可以看出策略模式和状态模式的应用场景有很大的不同；一个是封装一系列平行且复杂多变的实现方式，一个是实现把对象的内在状态的变化封装起来，用外部行为来表现出来；
状态模式的应用可以应用于lf-else冗长的判断，在《大话设计模式》一书中，就是这样的应用；我们知道，if-else是一种状态的匹配，
比如：
If(man.state.equals(State.passion)){
//workingHard
}else if(man.state.equals(:State.tired)){
//haveARest
}else if(….){
//otherActive
}
当我们在执行这段程序的时候，我们的状态就要从第一个if-else开始匹配；那么，我们知道，注释中的语句是对应的不同的状态的，我们匹配的字段是决定我们处于那个字段的，state是man的属性字段，我们用这个man的属性字段来匹配一个状态的属性字段，一旦匹配了以后，则执行这个属性能胜任的行为，不匹配则自动转换一个状态，再执行匹配；
详细代码如下：
对象类：（状态的具有者）
import org.state.IState;
public class Man {
private String stateStr = "tired";
private IState state = new PassionStateImp();//把最常用或者最初状态放//在这里，就好像进入if-else的判断入口；
public void request() {
state.handle(this);
}
public IState getState() {
return state;
}
public void setState(IState state) {
this.state = state;
}
public String getStateStr() {
return stateStr;
}
}
状态类：
状态接口：
package org.state;
import org.man.Man;
public interface IState {
public void handle(Man man);
}
亢奋状态：
package org.state;
import org.man.Man;
public class PassionStateImp implements IState {
public void handle(Man man) {
if (man.getStateStr().equals("passion")) {
System.out.println("i am working hander");//符合判断，则做出动//作
}else{
man.setState(new TiredStateImp());//继续匹配下一个状态
}
}
}
疲惫状态：
package org.state;
import org.man.Man;
public class TiredStateImp implements IState {
public void handle(Man man) {
if (man.getStateStr().equals("tired")) {
System.out.println("i must have a rest");
} else {
System.out
.println("i don't know what's wrong,i think i must be ill");
}
}
}
大家就会说，其实还是要进行if-else判断的，对没错，我们只是把if-else判断分成很多个小的if-else判断，在代码大全和重构两书里面，我们都看见过专家们对“冗长子程序“的担忧，认为子程序如果过长的话，代码就会有“坏味道”，子程序过长，就想问问自己是在写面的过程的代码，还是面向对象的代码，在上述的代码中，我们把state的类给抽象出来，方便以后对state进行扩充，就好比，我们这里的ill状态什么的不做，只是呻吟了一句“oh，I must be ill”；没有去打针，没有去看病，如果以后要实现的话，我们不得不去修改那些已经完全成型的代码，去看那个长长的if-else（虽然我们这里不长，但是你在代码大全里面应该见过保险企业的保费的计算吧，）而我们这里很好的做到了开闭原则，只要做出简单的修改就可以了；主要的工作在于扩展state的illStateImp子类；这是状态模式的一种应用；
状态模式最经典的应该，还是在于行为改变状态，状态决定行为的应用场景，我们在策略模式里面，可以清晰的看见，采用那种算法，哪么就让context实现那种算法，其决定权在于我们，在于客服端，这个context本身不能决定，算法对象本身不能决定，因为他是死的；
而在状态模式里面不同，如下：
一辆汽车开进停车场有一下流程：
1：准备进入停车场，到收费站停下；（检查状态）
2：允许进入
3：进入关卡状态）
4：停止车位 （已泊车状态）
5：开车出关卡 （装备出关状态）
6 允许出去
7 出关状态
在上述流程中，我们可见我们汽车的状态是不断变化的，状态的变化是行为影响的；
我们可以在状态的handle方法中间，根据客观条件和情况来改变状态
比如在检查状态的handle处理过程中我们这样：
if(allowEnter){
//set the state to enter state //大大方方的进去了
}else{
//set the state to goBack state//只能回家或者走后门啦
}
清晰的看见状态影响行为的过程；
从上面，我们可以看出，虽然两个孪生兄弟外表很像，但是性格还是相距甚远的；: -
联系客服
