状态模式主要可以用于这种场景
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过程中,没有必要去刻意使用某种姿势。一切还是看需求和感觉。