状态模式主要可以用于这种场景

1 一个对象的行为取决于它的状态

2 一个操作中含有庞大的条件分支语句

回想下街头霸王的游戏。

隆有走动，攻击，防御，跌倒，跳跃等等多种状态，而这些状态之间既有联系又互相约束。比如跳跃的时候是不能攻击和防御的。跌倒的时候既不能攻击又不能防御，而走动的时候既可以攻击也可以跳跃。

要完成这样一系列逻辑, 常理下if else是少不了的. 而且数量无法估计, 特别是增加一种新状态的时候, 可能要从代码的第10行一直改到900行.

if ( state === 'jump' ){    if ( currState === 'attack' || currState === 'defense' ){      return false;    } }else if ( state === 'wait' ){    if ( currState === 'attack' || currState === 'defense' ){      return true;    } }

为了消灭这些if else, 并且方便修改和维护, 我们引入一个状态类.

var StateManager = function(){   var currState = 'wait';   var states = {     jump: function( state ){     },     wait: function( state ){     },     attack: function( state ){     },     crouch: function( state ){     },     defense: function( state ){       if ( currState === 'jump'  ){           return false;  //不成功，跳跃的时候不能防御       }     //do something;     //防御的真正逻辑代码, 为了防止状态类的代码过多, 应该把这些逻辑继续扔给真正的fight类来执行.     currState = 'defense'; //  切换状态     }   }   var changeState = function( state ){     states[ state ] && states[ state ]();   }   return {       changeState  : changeState   } } var stateManager = StateManager(); stateManager.changeState( 'defense' );

通过这个状态类，可以把散落在世界各地的条件分支集中管理到一个类里，并且可以很容易的添加一种新的状态。而作为调用者，只需要通过暴露的changeState接口来切换人物的状态。

/***************************分界线1******************************************/

GOF提出的23种设计模式，至此已经写完大半。还有一些要么是js里不太适用，要么是js中已有原生自带的实现，所以就没再去深究。这2篇文章里 的大部分例子都来自或改写自工作和学习中的代码。我对设计模式的看法是不用刻意去学习设计模式，平时我们接触的很多代码里已经包含了一些设计模式的实现。 我的过程是读过prototype和jquery的源码后，回头翻设计模式的书，发现不知觉中已经接触过十之六七。

同样在实际的编码中也没有必要刻意去使用一些设计模式。就如同tokyo hot 32式一样，在一场友好的papapa过程中，没有必要去刻意使用某种姿势。一切还是看需求和感觉。