《研磨设计模式》读书笔记之：策略模式、状态模式

前言：本篇系看完《研磨设计模式》一书的个人理解和总结，可能存在不正确的地方，看时需要持怀疑态度。另外，所有的图都是示意图，示意，示。

策略模式（Strategy）:

几点解释：

1. 多个if、elif 相连的代码我们实际开发中肯定经常遇到，如果 if、elif的方法体都很大，那就可以考虑使用策略模式，抽象出统一的接口，并将方法体的逻辑剥离出来封装为接口的不同实现类。这样做扩展性得到了提高。
2. 各个策略类之间是平等的，可以相互替换。选择策略可以是客户端来主动选择，也可以是上下文对象自动的进行选择（容错恢复）。
3. 从结构上看，策略模式只有一层或者说是一级，如果需要多级的类似于折上折的功能，可以考虑装饰模式。
4. 如果去掉了Context类，则策略模式就变成了最常见的面向接口编程的 接口-实现类的结构。但是，上下文对象在策略模式中扮演了重要的角色，我们从Strategy接口的 someOperation(Context context)方法可以看出，上下文对象提供给策略实现类一个统一的获取所需数据的方式，甚至是回调上下文的某些方法；另外，客户端直接持有和使用上下文对象，意味着策略对象可以独立于客户端而变化，并且可以在上下文中动态的切换策略。
5. 本质是 分离算法，并封装为具体的类，自由的选择算法的实现。

状态模式（State）:

几点解释：

1. 这图是上面策略模式的图改的，状态模式的结构和策略模式一模一样。但是二者明显的区别在于：状态模式中，一个状态对应一个行为，行为完全不同并且不可替代，是平行的，而 策略模式中，不同的策略类之间平等的，即 彼此可以灵活替换。
2. 状态模式的重心在于：首先，分离总结出业务中的 几种状态，然后再将各个状态对应的行为剥离出来，封装为同一个抽象的不同实现。
3. 通常，业务中的状态应当是固定的几种，而 不同的状态也对应了特定的行为。因此，通常在上下文对象中实现好根据状态选择具体行为的逻辑，客户端不必参与。这点也不同于策略模式，策略模式由于策略类的平等性，客户端和上下文对象都可以灵活的选择对应的策略。
4. 策略模式和状态模式有一个共同的问题，会产生很多的细粒度对象，而且 策略类和状态类一般是无状态的，所以在频繁使用的情况下，很适合使用 享元模式来达到延迟创建并缓存共享的功能。