设计模式之策略模式和状态模式
之前的一段时间一直在学习设计模式相关知识，学习一段时间后发现，设计模式不能算是知识点，其仅仅是一种思想，我们应该在日常的开发设计中潜移默化的应用这种思想，而不是为了模式而模式。言归正传，今天我想来叨叨策略模式和状态模式。
先看看他们的UML图
两个模式的UML图基本上是相同的。
策略模式的Context含有一个Strategy的引用，将自身的功能委托给Strategy来完成。
将上面的UML图中的Strategy接口改个名字为State，这就是状态模式了，同样Context也有一个State类型的引用，也将自己的部门功能委托给State来完成。
他们之间真正的区别在策略模式对Strategy的具体实现类有绝对的控制权，即Context要感知Strategy具体类型。而状态模式，Context不感知State的具体实现，Context只需调用自己的方法，这个调用的方法会委托给State来完成，State会在相应的方法调用时，自动为Context设置状态，而这个过程对Context来说是透明的，不被感知的。
设计模式五大设计原则：SOLID，S 单一职责，O 对修改关闭对扩展开放，L 里式替换，I 接口隔离，D 依赖倒置
1.这两种模式没有明确的遵循单一职责的原则
2.两种模式都依赖的是上层接口，符合对修改关闭对扩展开放原则
3.显然子类的实现类都可以替换Context中接口的引用的，符合里式替换
4.接口隔离暂未体现
5.依赖倒置目前我是没看出来。工厂模式诠释了依赖倒置，高层调用和底层对象的产生都依赖抽象，而非具体实现，我会在稍后的系列中提到。
再谈两种模式的使用，相对来说策略模式比状态模式简单一点。
- 策略模式的控制权在客户端，业务逻辑能够很好的剥离。而状态模式需要我们对整个业务中的状态进行抽象，并且需要对顶层State接口中的方法进行抽象。
- State的方法中需要对Context的状态进行管理，这也增加了一定的复杂性。
PS：我更愿意将Context中Strategy引用的成员变量理解为委托，在运行时可以动态的改变Strategy的实现类，这比继承更加灵活。
