设计模式中的delegation总结

---

前言

复习了一遍软件构造，感觉设计模式那一块特别有意思，特别是其中对delegation的使用，很精妙，所以总结一下几个我觉得比较值得一提的模式中的delegation。

---

1. 工厂方法模式

在这种模式下，可以看做有两棵树，一棵为产品树，一棵为工厂树。在创建产品这件事上，客户端面对的完全是工厂树的实现类，不会接触到产品树。创建具体产品被委托给了具体的工厂的某些类似于createProduct的方法。
在新加入产品时，对已有的代码不用做任何修改，只要新建一个产品以及对应工厂即可，符合开闭原则。

2. 适配器模式

在适配器模式中，适配器类将客户端的请求委托给适配的类，以实现接口的兼容性。这种委托关系使得适配器模式能够在不改变现有类的情况下，通过引入一个新的适配器类来实现不同接口之间的协作。
在适配器类中的对应函数中，new了一个原有类的对象，把经过处理的参数传给这个原有类的对象，实现了delegation。适配器类可以当成是一个兼容的原有类使用，它的地位和原有类本应在继承树中的地位应该是一模一样的。

3. 装饰器模式

以这张图片举例，装饰器的委托的最大头，就是在于除了最基础的功能实现类ConcreteComponent之外，所有的装饰类都保有一个最抽象接口类Component的字段引用，并在其构造函数中选择实现类对象被这个引用指向。
由于保有的是接口类，所以全部都是父类引用指向子类对象的关系，它可以被传入最抽象接口的所有实现类，并在当前类的构造中，把部分功能委派给这个成员，再添加自己的额外行为。所有实现类的共同接口保证了组合的自由性，装饰类的继承实现了功能的叠加。
通过这种方式，装饰器模式动态地为对象添加职责（功能）。这种模式为对象的功能扩展提供了一种灵活的机制，同时保持了对象设计的开放封闭原则。

4. 策略模式

在策略模式中，delegation起到了核心作用。

首先有一棵功能实现的继承树，比如说支付功能：

creditCardStrategy与PaypalStrategy是实现了PaymentStrategy的两种方式，客户端需要delegation给他们实现自己的不同支付方式，这里应用了松散的delegation即association，通过传参建立委派关系。
在客户端中，面对某个功能有多种实现的情况，该功能的参数列表中的是所有实现的抽象接口，这样就可以通过传入不同的实现类对象，对功能进行不同的实现。

传入不同的参数，就按不同的方式实现接口规定的那个功能；在扩展方式时，也只需要再实现一个PaymentStrategy的子类，客户端传这个子类就行，符合开闭原则。

5. 观察者模式

Visitor模式包括以下主要角色：

元素接口（Element）：定义一个accept方法，接受访问者对象。
具体元素（Concrete Element）：实现元素接口，定义accept方法的实现。
访问者接口（Visitor）：定义访问不同元素的方法。
具体访问者（Concrete Visitor）：实现访问者接口，实现对不同元素的操作。

在Visitor模式中，元素对象将自身的处理逻辑委托给访问者对象。具体来说，元素对象在accept方法中调用访问者对象的对应方法，将处理逻辑委托给visitor的实现类。

---

对element的很多操作不在element中定义，而是通过它的accept方法delegate给visitor。
accept方法的形参列表中，是visitor树中的最大接口，便于接受每一个visitor实现类实例，在visitor树中，最大接口决定了要对哪些element进行操作，每个实现类代表对最大接口决定的要操作的一系列element类的具体操作，要切换操作算法，只要传入不同visitor子类对象。
所以在扩展中，添加操作很容易，只要在visitor接口下实现一个新的子类
而添加element很麻烦，因为要从接口开始添加一个要操作的element，所有visitor的实现类都要修改。