第七章 时势造英雄 – 策略模式
策略模式的定义
- 策略模式定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。
- 策略模式让算法独立于使用它的客户而独立变化。
策略模式的使用场景
- 针对同一类型问题的多种处理方式，仅仅是具体行为有差别时。
- 需要安全地封装多种同一类型的操作时。
- 出现同一抽象类有多个子类，而又需要使用if-else 或者switch-case 来选择具体子类时。
策略模式的 UML 类图
Context：用来操作策略的上下文环境Stragety：策略的抽象ConcreteStragetyA、ConcreteStragetyB：具体的策略实现。
策略模式小结
- 策略模式主要用来分离算法，在相同的行为抽象下有不同的具体实现策略。
- 这个模式很好地演示了开闭原则，也就是定义抽象，注入不同的实现，从而达到很好的可扩展性。
- 优点
- 结构清晰明了、使用简单直观
- 耦合度相对而言较低，扩展方便
- 操作封装也更为彻底，数据更为安全。
- 缺点
- 随着策略的增加，子类也会变得繁多。
第八章 随遇而安 – 状态模式
状态模式的定义
- 当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。
状态模式的使用场景
- 一个对象的行为取决于它的状态，并且它必须在运行时根据状态改变它的行为。
- 代码中包含大量与对象状态有关的条件语句，且这些分支依赖干该对象的状态。
状态模式的 UML 类图
-
Context：环境类，定义客户感兴趣的接口，维护一个 State 子类的实例，这个实例定义了对象的当前状态。 -
State：抽象状态类或者状态接口，定义一个或者一组接口，表示该状态下的行为。 -
ConcreteStateA、ConcreteStateB：具体状态类，每一个具体的状态类实现抽象 State 中定义的接口，从而达到不同状态下的不同行为。
状态模式小结
-
状态模式的关键点在于不同的状态下对于同一行为有不同的响应，这其实就是一个将if-else用多态来实现的一个具体示例。
-
优点
- State 模式将所有与一个特定的状态相关的行为都放入一个状态对象中，它提供了一个更好的方法来组织与特定状态相关的代码，将烦琐的状态判断转换成结构清晰的状态类族,在避免代码膨胀的同时也保证了可扩展性与可维护性。
-
缺点
- 状态模式的使用必然会增加系统类和对象的个数。
