设计形式读书笔记-状态模式

设计模式读书笔记-----状态模式

       在介绍状态模式之前，我们先来看这样一个实例：你公司力排万难终于获得某个酒店的系统开发项目，并且最终落到了你的头上。下图是他们系统的主要工作(够简单)。

       当你第一眼看到这个系统的时候你就看出来了这是一个状态图，每个框框都代表了房间的状态，箭头表示房间状态的转换。分析如下：房间有三个状态：空闲、已预订、已入住，状态与状态之间可以根据客户的动作来进行转换。定义每个状态的值。

       状态模式包含如下角色：
       Context: 环境类。可以包括一些内部状态。 
       State: 抽象状态类。State定义了一个所有具体状态的共同接口，任何状态都实现这个相同的接口，这样一来，状态之间就可以互相转换了。
       ConcreteState: 具体状态类。具体状态类，用于处理来自Context的请求，每一个ConcreteState都提供了它对自己请求的实现，所以，当Context改变状态时行为也会跟着改变。
       三、模式实现
       依然是上面那个酒店的实例。对于该实例的UML图如下：

       首先是状态接口：State


       四、模式优缺点       优点
       1、封装了转换规则。
       2、枚举可能的状态，在枚举状态之前需要确定状态种类。 
       3、将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。
       4、允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。 
       5、可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。
       缺点
       1、状态模式的使用必然会增加系统类和对象的个数。
       2、状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。
       3、状态模式对“开闭原则”的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态；而且修改某个状态类的行为也需修改对应类的源代码。
       五、模式适用场景
1、对象的行为依赖于它的状态（属性）并且可以根据它的状态改变而改变它的相关行为。 
2、代码中包含大量与对象状态有关的条件语句
       六、模式总结
       1、状态模式允许一个对象基于内部状态而拥有不同的行为。
       2、Context会将行为委托给当前状态对象。
       3、状态模式对“开闭原则”支持不是很好。