目录
掌握的知识点
- 设计模式分为哪3类
- 每一类包含哪些具体的设计模式
创建型
创建型模式是对对象实例化过程的抽象，他通过抽象类所定义的接口，封装了系统中对象如何创建、组合等信息。
创建型模式主要用于创建对象，做到了软件模块跟对象的创建无关联
包括的设计模式有：
- 抽象工厂模式
- 建造者模式
- 工厂方法模式
- 原型模式
- 单例模式
结构型
结构型模式主要用于如何组装已有的类和对象，已获得更大的结构，一般借鉴封装、代理、继承等概念讲一个或者多个类进行组合、封装，已提供统一的外部视图或新的功能。
主要负责处理类或对象之间的关系，将类和对象进行有效组织，形成良好的体系结构
主要的模式包括：
- 适配器模式
- 桥接模式
- 组合模式
- 装饰器模式
- 外观模式
- 享元模式
- 代理模式
行为型
该模式主要用于对象之间的职责以及提供的服务的分配，不仅描述对象或类的模式，还描述他们之间的通信模式，特别是描述一组对等的对象怎样相互协作以完成其中任一对象都无法单独完成的任务。
主要处理类和对象之间的交互方式，以及如何为类和对象分配职责进行描述
主要的模式包括：
- 责任链模式
- 命令模式
- 解释器模式
- 迭代器模式
- 中介者模式
- 备忘录模式
- 观察者模式
- 状态模式
- 策略模式
- 模板方法模式
- 访问者模式
例子：
由于传统的结构化的软件设计方法不符合面向对象的设计原则，无法很好地实现高内聚低耦合的要求，模块之间过于紧密，给软件扩展和维护带来很多困难，这种情况下设计模式的出现和广泛应用给问题的解决提供了一种有效的方法，通过利用设计模式，可帮助开发者利用已有的设计方法，设计出结构合理、易于复用和可维护的软件，当用户需求发生改变时，可通过修改少量代码或不修改原有代码即可满足新的需求，增强了系统的可修改性和稳定性，降低系统开发成本。
strategy，属行为型，定义一系列算法，把它们一个个封装起来，并且使它们之间可互相替换，从而让算法可独立于使用它的用户而变化。在监控模块的告警功能上，我们监控的各软件的前端界面上可由用户配置接收告警信息的方式，例如默认钉钉另有短信、微信、电话语音，定时任务在监控到有异常且满足发告警的情况下，后端代码会获取到用户配置的信息，根据配置信息调用指定的策略发送告警信息，具体实现是，先抽象出基类class AlarmSender，子类扩展基类class DingSender(AlarmSender)、class SMSSender(AlarmSender)等，并在子类中定义具体实现def send(self, info)，假设当前有RabbitMQ告警且用户配置的是默认钉钉方式，则在发告警时的代码为先实例化mq_ins = MQInfo(info='告警内容', way=[DingSender])，way为具体的发告警的方式，再调用mq_ins.way.send(info)完成发送告警。使用这种模式我们发现，发告警的方式（即算法）可自由切换，将发告警的类名作为参数传入即可，这也是依赖抽象类设计接口的好处之一，还减少代码冗余，扩展性好，移植方便，使用灵活。
例子2：
策略模式：
在系统中，设计到住户缴费的功能，目前的线上缴费渠道有多种，如微信，支付宝，银联支付等多种。各个支付渠道的算法又不相同，起初我们用多重条件判断，涉及各个渠道支付实现的算法又包含重条件判断，这样定义后，发现代码不够简洁，也不利于维护，经过分析后，我们选择采用策略模式，首先定义了一个paystrategy接口作为抽象角色，然后定义了如alipaystrategy,wechatpaystrategy,unicompaystrategy具体角色，这些具体实现类里封装了对于支付方式的算法，并且这些类实现paystrategy了接口。定义了paycontextstartegy，该类引用了paystrateg.当web请求支付，并且带有支付方式的pay_code; controller接到请求后，使用paycontextstartegy调用具体的支付类如alipaystategy,wechatpaystategy,uniompaystrategy.通过使用策略模式，我们实现了不同方式的支付自由切换，避免了多次条件判断，利用组合代替继承，将算法的选择和算法的实现分开，降低了程序间的耦合度，具有很好的扩展型和可维护型。
例子3：
责任链模式：责任链模式是一种行为设计模式， 允许你将请求沿着处理者链进行发送。 收到请求后， 每个处理者均可对请求进行处理， 或将其传递给链上的下个处理者。
测试平台：
请求---拼装公共参数(环境信息，公共配置)----替换个性化参数---替换上下文参数
