GeekBand-笔记-设计模式-01

手打不容易啊……

1、 内容来自《Design Patterns Explained》一书。
2、 2、附有Python代码，个人觉得，更清晰易懂，但是需要注意，Python代码与“实现”的文字描述不一致，与C++或者Java风格的模式演示代码也不一致。代码来自https://github.com/faif/python-patterns
3、 文中的Python代码都是图片，jianshu无法粘贴图片，需要看到图片请下载pdf格式附件或者自行到github上下载。

一、模板方法
模板方法（Template Method）通常用于定义一个操作中算法的骨架，而将一些步骤延迟到子类中，不改变算法的结构就可以重新定义它的步骤。

其关键特征：
1、 意图：定义一个操作中算法的骨架，将一些步骤推迟到子类中实现。可以不改变算法的结构而重新定义该算法的步骤。
2、 问题：要完成在某一细节层次一致的一个过程或一系列步骤，但其个别步骤在更详细的层次上的实现可能不同。
3、 解决方案：允许定义可变的子步骤，同时保持基本过程一致。
4、 参与者与协作者：Template Method模式由一个抽象类组成，这个抽象类定义了需要覆盖的基本TemplateMethod方法，每个从这个抽象类派生的具体类将为此模板实现新方法。
5、 效果：模板提供了一个很好的代码复用平台，它还有助于确保所需步骤的实现。它将每个concrete类的覆盖步骤绑定起来，因此只有在这些变化总是并且只能一起发生时，才应该使用TemplateMethod模式。
6、 实现：创建一个抽象类，用抽象方法实现一个过程，这些抽象方法必须在子类中实现，以执行过程的整个步骤。这些步骤是独立变化的，那么每个步骤都可以考虑使用Strategy模式来实现。
7、 Python代码：

二、策略模式
策略模式（Strategy Pattern）能把一系列“可互换的”算法封装起来，并根据用户的需求来选择其中一种。

其关键特征：
1、 意图：可以根据所处上下文，使用不同的业务规则或算法
2、 问题：对所需算法的选择，取决于发出请求的客户或者要处理的数据。如果只有一些不会变化的算法，就不需要此模式。
3、 解决方案：将对算法的选择和算法的实现相分离。允许根据上下文进行选择。
4、 参与者与协作者：
a、 Strategy指定了如何使用不同的算法
b、 各ConcreteStrategy实现了这些不同的算法
c、 Context通过类型为Strategy的引用使用具体的ContextStrategy。Strategy与Context相互作用以实现所选择的算法，有些时候，Strategy必须查询Context，Context将来自Client的请求转发给Strategy。
5、 效果：
a、 Strategy模式定义了一系列的算法
b、 可以不使用if语句或者switch语句
c、 相异的算法拥有相同的接口，必须以相同的方式调用所有的算法。
d、 各ContextStrategy与Context之间的相互作用可能需要在Context中加入获取状态的方法
6、 实现：让使用算法的类（Context）包含一个抽象类（Strategy），该抽象类有一个抽象方法指定如何调用算法。每个派生类按需要实现具体的算法。
7、 python代码：

三、观察者模式
观察者模式（Observer Pattern）常用于处理对象间一对多的依赖关系，当某对象改变状态时，所有相关对象都会得到通知并自动更新。

其关键特征：
1、 意图：在对象之间定义一种一对多的依赖关系，这样当一个对象状态改变时，所有依赖者都将得到通知并自动更新。
2、 问题：当某个事件发生时，需要向一系列变化着的对象发出通知。
3、 解决方案：Observer将监视某个事件的责任委托给中心对象：Subject。
4、 参与者与协作者：Subject知道自己的Observer，因为Observer要向它注册。Subject必须在所监视的事件发生时通知Observer。Observer负责向Subject注册并在获得通知时，从Subject处获取信息。
5、 效果：如果某些Observer只对事件的一个子集感兴趣，那么Subject可能会告知它不想要知道的事件。如果Subject通知了Observer，Observer还需要更多的信息，可能需要另外的通信。
6、 实现：
a、 让某个事件发生时需要知道的对象（Observer）将自己注册到另一个监视事件发生或自己触发事件的对象（Subject）上。
b、 事件发生时，Subject告诉Observer事件已经发生
c、 为了对所有的Observer类型的对象实现Observer的接口，有需要需要使用Adaptec模式。
7、 Python代码：

四、装饰模式
装饰模式（Decorator Pattern）用于动态的给一个对象添加一些额外的职责，就增加功能来说，Decorator Pattern比生成子类更为灵活。

其关键特征：
1、 意图：动态的给一个对象添加职责。
2、 问题：要使用的对象将执行所需的基本功能。但是，某些时刻可能需要为这个对象添加某些功能，这些附加功能可能发生在对象的基础功能之前或之后。这是个常用的模式，比如说，Python天然就支持。
3、 解决方案：可以无需创建子类，而扩展一个对象的功能。
4、 参与者与协作者：ConcreteComponent让Decorator对象为自己添加功能。有时候用ConcreteComponent的派生类提供核心功能，在这种情况下，ConcreteComponent类就是抽象的。Component类定义了所有这些类所使用的接口。
5、 效果：所添加的功能放在小对象中，好处是可以在ConcreteComponent对象的功能之前或者之后动态添加功能。注意，虽然装饰对象可以在被装饰的对象之前或只有添加功能，但是对象链总是终于ConcreteComponent对象。
6、 实现：创建一个抽象类来表示原类和要添加到这个类的新功能。在装饰类中，将对新功能的调用放在对紧随其后对象的调用之前或之后，以获得正确的顺序。
7、 Python代码：

五、桥模式
桥模式（Bridge Pattern）用于将抽象（比如接口，比如算法等）与实现方式相分离，解耦后的抽象与实现方式可以独立的变化。

其关键特征：
1、 意图：将一组实现与另一组使用它们的对象分离。
2、 问题：一个抽象类的派生类必须使用多个实现，但不能出现类数量爆炸性的增长。
3、 解决方案：为所有实现定义一个接口，供抽象类的所有派生类使用。
4、 参与者与协作者：Abstraction为要实现的对象定义接口，Implementor为具体的实现类定义接口。Abstraction烦人派生类使用Implementor的派生类，却无需知道自己具体使用了哪一个ConcreteImplementor。
5、 效果：实现与使用实现的对象解耦，提供了可扩展性，客户对象无需操心实现问题。
6、 实现：
a、 将实现封装在一个抽象类中
b、 在要实现的抽象的基类中包含一个实现的句柄，
7、 Python代码