前言
本文为datawhale2022年12月组队学习《大话设计模式》task6打卡学习。
【教程地址】https://github.com/datawhalechina/sweetalk-design-pattern
一、桥接模式
1.1 基本定义
桥接模式（Bridge Pattern）又称为柄体(Handle and Body)模式或接口(Interfce)模式，是将抽象部分与其实现部分分离，使它们都可以独立地变化。
1.2 问题引入
有不同品牌的手机，同时这些手机上还要安装不同的应用软件，考虑在需要不断增加软件的情况下，如果设计相应的抽象类。
需要注意对于不同品牌的手机，软件基本无法兼容。因此如果手机需要增加软件，就需要针对不同品牌的手机分别实现软件功能。
1.2.1 问题分析
实现该问题的程序通常会采用继承方式设计，那么父类和子类之间会具有非常紧密的依赖关系，父类中的任何变化都会影响子类，子类继承的实现如果无法解决新需求就必须重写或替换父类。如此设计会导致类爆炸问题，并且扩展不灵活。
1.2.2 问题解决
考虑到单独使用品牌或单独使用软件作为抽象类，都会在有新的需求来临后使得父类必须重写。因此需要使用合成/聚合原则代替类继承思想设计程序，是应该有个“手机品牌”抽象类和“手机软件”抽象类，让不同的品牌和功能都分别继承于它们，这样要增加新的品牌或新的功能都不用影响其他类了。结构图：
在工程中，包括以下四个角色：
- Abstraction（抽象类）：用于定义抽象类的接口，其中定义了一个具有关联关系的Implementor 的对象。
- RefinedAbstraction（扩充抽象类）：继承并实现抽象类中的接口，并在其中调用Implementor 对象的相关业务方法。
- Implementor（实现类）：用于定义实现类的接口，提供基本的业务方法供抽象类调用，以完成复杂的操作。
- ConcreteImplementor（具体实现类）：继承并实现 Implementor 的接口，在不同的具体实现类中提供不同的操作方法，通过向上转型的方式完成方法的调用。
1.2.3 代码实现
官方源码链接：
桥接模式Java实现
桥接模式python实现
1.3 应用场景
客观来说这个刚接触确实很难直接应用，但是一旦理解透彻对于面向对象设计有非常大的帮助。有以下情况，可以尝试使用：
- 1.“抽象部分”和“实现部分”可以以继承的方式独立扩展而互不影响，在程序运行时可以动态将一个抽象化子类的对象和一个实现化子类的对象进行组合，即系统需要对抽象化角色和实现化角色进行动态耦合。
- 2.一个类存在两个（或多个）独立变化的维度，且这两个（或多个）维度都需要独立进行扩展。
- 3.对于那些不希望使用继承或因为多层继承导致系统类的个数急剧增加的系统，桥接模式尤为适用。
1.4.1 优点
- 在很多情况下，桥接模式可以取代多层继承方案，多层继承方案违背了“单一职责原则”，复用性较差，且类的个数非常多，桥接模式是比多层继承方案更好的解决方法，它避免了继承导致的类爆炸问题。
- 具备灵活的可扩展性，在两个变化维度中任意扩展一个维度，都不需要修改原有系统，符合“开闭原则”。
1.4.2 缺点
- 将抽象和实现分离会增加设计的难度，由于关联关系建立在抽象层，要求开发者一开始就针对抽象层进行设计与编程。
- 桥接模式要求正确识别出系统中两个独立变化的维度，因此其使用范围具有一定的局限性，如何正确识别两个独立维度也需要一定的经验积累。
二、职责链模式
2.1 基本定义
职责链模式（Chain of Responsibility）也叫责任链模式，是一种对象行为型模式。为了避免请求发送者与多个请求处理者耦合在一起，于是将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止。
职责链模式核心是解决服务中先后执行处理关系，从而降低请求发送者和接受者之间的耦合关系。类似于击鼓传花。
2.2 问题引入
要用程序实现加薪、请假申请等需要层层审批的场景。比如向经理提加薪申请，经理没权利然后向总监上报，总监没权限然后向总经理汇报等。
2.2.1 问题分析
如果将管理者创建成为一个类，那么该类会具有太多的责任，比如经理、总监以及总经理的审批和上报功能，就违背了单一职责原则。而且以后的需求可能会增加新的管理类别，比如项目经理、部门经理、人事总监等，那么就势必会修改管理者类以完成扩展，就违背了开放封闭原则。
2.2.2 问题解决
将公司管理者的类别变成管理者的子类，可以通过多态性来化解分支带来的僵化。然后通过不同管理者之间建立管理关系实现请求的传递，使得请求的发送者和接收者解耦，可以让各服务模块更加清晰。处理者负责处理请求，客户只需要将请求发送到职责链，无需关心具体的处理细节。
其中有两个关键类：
- Handler(请求类)：用于定义一个处理请示的接口。
- ConcreteHandler(具体处理者类)：处理它所负责的请求，可访问它的后继者，如果能够处理就处理，否则就将请求转发给它的后继者。
2.2.3 代码实现
官方源码链接：
职责链模式Java实现
职责链模式python实现
2.3 应用场景：
责任链模式通常在以下几种情况使用。
- 1.有多个对象可以处理一个请求，哪个对象处理该请求由运行时刻自动确定。
- 2.可动态指定一组对象处理请求，或添加新的处理者。
- 3.在不明确指定请求处理者的情况下，向多个处理者中的一个提交请求。
2.4 优缺点
2.4.1 优点
- 能够简化对象的相互连接，接收者和发送者都没有对方的明确信息，且链中的对象也不知道链的结构。
- 避免了请求的发送者和接受者之间的耦合关系。
- 能够随时修改请求的结构，增强了给对象指派职责的灵活性
2.4.2 缺点
- 请求可能到了链的末端都得不到处理，或者因为没有正确配置得不到处理。
- 较长的责任链可能会影响到系统的性能。
三、中介者模式
3.1 基本定义
中介者模式（Mediator Pattern）又叫又叫做调停者模式。它提供了一个中介类，用一个中介对象来封装一系列的对象交互。
中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们的交互。中介者模式属于行为型模式，用来降低多个对象和类之间的通信复杂性。
3.2 问题引入
刚进公司的新人需求其他部门同事帮忙是有困难的，但是通过主管协调就会简单许多。
3.2.1 问题分析
将系统分割成许多对象通常可以增加其复用性，但是对象之间大量的连接又使得对象之间的耦合性更强，导致对系统的行为进行较大的改动就比较困难。
3.2.2 问题解决
通过中介者对象，可以将系统的网状结构变成以中介者为中心的星型结构，使得对象之间的耦合度变低、扩展性增强，系统的结构不会因为新对象的引入造成大量的修改工作。
在工程中，有以下四个关键类：
- Mediator(抽象中介者类)：定义了同事对象到中介者对象的接口。
- ConcreteMediator(具体中介者对象)：实现抽象类的方法，知道所有具体同事类，并从具体同事接受消息，向其他具体同事发送命令。
- Colleague(抽象同时类)：用于定义抽象的同事对象。
- ConcreteColleague(具体同时类)：每个具体同事只知道自己的行为，而不了解其他同事类的情况，但是他们认识终结者对象。
3.2.3 代码实现
官方源码链接：
中介者模式Java实现
中介者模式python实现
3.3 应用场景
中介者模式一般应用于一组对象以定义良好但是复杂的方式进行通信的场合。以及想定制一个分布在多个类中的行为，而又不想生成太多的子类的场合。
3.4 优缺点
3.4.1 优点
- 中介者减少了各个业务类的耦合，使得可以独立的改变和复用各个业务类和中介者类。
- 中介者的实现类控制了集中化，把对象群交互的复杂性变为中介者的复杂性。
- 当系统出现多对多交互复杂的对象群，可以考虑使用中介这模式。
3.4.2 缺点
中介者会变得庞大且复杂，原本多个对象直接的相互依赖变成了中介者和多个同事类的依赖关系，同事类越多，中介者的逻辑就越复杂。
参考
[1] datawhale大话设计模式教程云 - GitHub
[2] 秒懂设计模式之桥接模式（Bridge Pattern）
[3] 设计模式（十四）中介者模式
