拿常见的怪物设计来说，大概最初的设计哀求只要做到：怪物能旁边巡逻，剖断有敌方单位则进行攻击。就这么点需求，那不是一个if-else的小case？你真这么想，而且还这么干了的话，那你可就太年轻了。最大略的，角色可能涌现俯冲攻击，或者说攻击过程中被冰冻，或者移动的时候跳跃可能都对应不同的状态，如果都通过增加变量来剖断的话，一个剖断条件会越来越多，更关键的如果中间再插入点新的需求的话，可能看到那个代码都无从下手了。
这时候，关键词“状态”涌现了。最大略的一个做法便是引入状态机。通过列举将状态列举清楚，每一个状态就只做对应的业务。例如
enum State { STANDING, JUMPING, DUCKING, DIVING};
通过列举的办法，避免了大量的状态标志位，这样可以通过Switch将一个处理单个状态代码封装到一起。对付不是特殊繁芜的战斗，实在已经能大略的办理大部分问题了。但是如果状态之间如果涌现了变量穿插，可能就会涌现新的问题了。例如角色在躲避攻击的时候能蓄能，在能量加满的时候会开释分外技能。这个时候我们就得增加新的成员变量，并且须要修正到两个状态的代码。
有没有更好的办法办理这种问题呢？敬请期待下回分解
