监听模式（观察者模式）
概念
监听模式为一对多的关系，可以有任意个观察者对象同事监听某一个对象。
监听的对象为观察者，被监听的对象为被观察者。
被观察者发生变化时，会通知所有观察者。
设计思想
在被观察者与观察者之间建立一种自动触发的关系。
模型说明
- 明确观察者与被观察者
- Observable在发广播通知的时候，无需指定具体的Observer
- 被观察者至少需要有三个方法：添加监听者、移除监听者、通知Observer的方法
- 推模型：不管观察者是否需要，被观察者对象会把全部或部分信息通过update参数传递给观察者
- 拉模型：被观察者在通知观察者时传递少量信息，如果观察者需要详细信息时，由观察者主动到被观察者对象中获取，相当于观察者从被观察者对象中拉数据。
应用场景
一个对象状态或数据的更新需要其他对象同步更新时
一个对象的更新需要依靠另一个对象的更新
对象仅需要将自己的更新通知给其他对象而不需要知道其他对象的细节，如消息推送
状态模式
概念
一个对象在其内部状态发生改变时，其表现的行为和外在属性不一样，这个对象看上去就像改变了他的类型一样。
设计思想
一个对象有多种状态，在不同状态下所表现出来的行为属性不一样。
模型说明
每一种状态只有唯一的实例
优点：
- 封装了状态的转换规则，在状态模式中可以将状态的转换代码封装在环境类中，对状态转换代码集中管理。
- 将所有与某个主管你太有关的行为放到一个类中，使开发人员只专注于该状态下的逻辑开发。
- 允许状态转换逻辑与状态对象合为一体，使用时只需要注入一个不同的状态对象，使环境对象拥有不同的行为。
缺点：
- 会增加系统类和对象的个数。
- 状态模式的结构与实现都较为复杂，如果使用不当容易导致程序结构和代码的混乱。
应用场景
一个对象的行为取决于他的状态，他在运行时可能经常改变他的状态，从而改变他的行为。
一个操作中有庞大的多分支条件语句，这些分支依赖于该对象的状态，并且每个分支的业务逻辑很复杂时，可以使用状态模式来拆分不同的分支逻辑。
中介模式
概念
由中介来承接房客与房东之间的交互过程，可以使整个过程更加畅通、高效。又称为调停模式。
设计思想
在很多系统中多个类很容易互相耦合，形成网状结构。中介模式的作用就是将这种网状结构分离成星型结构，使对象间的结构更加简洁，交互更加流畅。
模型说明
交互对象：要进行交互的对象
中介者：负责协调各个对象之间的交互
优点：
- 中介者将原本分布在多个对象间的行为集中在一起，作为一个独立的概念并将其封装在一个对象中，简化了对象之间的交互。
- 将多对多的交互关系抓换为一对多的交互关系，减少了多个对象之间相互交叉引用的情况。
缺点：
- 交互的复杂度转变成了中介者的复杂度，中介者类会变得越来越复杂，难以维护。
- 中介者出问题会导致多个使用者同事出问题。
应用场景
想通过一个中间类来封装多个类中的行为，同时又不想生成太多子类。
一个对象引用其他很多对象，并且直接与这些对象通信，导致难以复用该对象。
装饰模式
概念
由结构庞大的子类继承关系转换成了结构紧凑的装饰关系。
设计思想
动态的给一个类增加额外的技能，而不改动原有的代码。
模型说明
可以灵活的给一个对象增加职责或拓展功能。
可以增加任意多个装饰。
装饰顺序不同，产生不同的效果。
优点：
- 可以在不创造更多子类的情况下将对象的功能加以扩展。
- 可以动态的给一个对象附加更多的功能。
- 可以用不同的装饰器进行多重装饰，装饰的顺序不同，可能产生不同的效果。
- 装饰类和被装饰类可以独立发展，不相互耦合，装饰模式相当与继承的一个替代模式。
缺点：
- 用装饰的方式拓展功能容易出错，排错也更困难。
python装饰器与装饰模式：设计思想相似，更好的拓展性，不需要改太多代码，增加额外功能。
应用场景
有大量独立的扩展。
需要动态的增加或撤销功能。
不能采用生成子类的方法进行扩充时，类的定义不能用于生成子类。
单例模式
概念
确保一个类只有一个实例，并且提供一个访问他的全局方法。
设计思想
保证一个类有且只有一个对象的一种机制，单例模式用来控制某些事物只允许由一个个体。
模型说明
定义静态的__instance类变量，用来存放Singleton1的对象，__new__方法每次返回同一个__instance对象（若未初始化则进行初始化）
只有一个类，类中只有一个方法，获取该类的唯一实例。
应用场景
你希望这个类只有一个且只有一个实例
全局管理类
克隆模式（原型模式）
概念
通过拷贝自身的属性来创建一个新对象的过程。
clone主要包括两个过程：分配一块新的内存空间给新对象、拷贝副本对象的所有属性。
尽量使用深拷贝的方式。
模型说明
优点：
- 克隆模式内存拷贝的方式进行复制，比new的方式创建对象性能更好。
- 通过深拷贝可以方便的创建一个具有相同属性和行为的另一个对象。
缺点：
- 通过克隆模式创建的对象，不会执行类的初始化函数。
应用场景
创建新对象成本高，可以利用已有对象进行复制。
类的初始化需要消耗非常多的资源。
可配合备忘录模式做一些备份工作。
职责模式（责任链模式）
概念
将请求的发送者和接收者解耦了，客户端不需要知道请求处理者的明确信息和处理的具体逻辑，只需要将请求发送即可。
设计思想
对于问题的处理流程使一手接一手的责任传递，处理问题的所有人构成了一条责任链，链上的每个人只需要处理自己职责范围内的请求，对于自己处理不了的请求，直接交规下一个责任人。
在职责模式中，可以随时随地增加或更改责任人，甚至可以更改责任人的顺序，增加了系统的灵活性，但有时候可能会导致一个请求无论如何也得不到处理，它会被放置在链条末端。
模型说明
请求者与请求内容：发送请求的对象为请求者，请求内容通过发送请求时的参数进行传递。
有哪些责任人：责任人是构成责任链上的关键要素。
对责任人进行抽象：责任人多种多样，有不同的责任和功能，他们都可以处理请求。
责任人可自由组合：责任链上的负责人可以根据业务的具体逻辑进行自由的组合和排序。
优点：
- 降低耦合度，请求的发送者和接收者解耦
- 简化了对象，对象不需要知道链的结构
- 增强给对象指派职责的灵活性，可改变链内成员的次序，允许动态的新增或删除责任人
- 增加新的处理类很方便
缺点：
- 保护能保证一定被接收
- 调试不便，可能会造成循环引用
应用场景
有多个对象可以处理同一个请求，具体哪个对象处理该请求在运行时自动确定
请求的处理具有明显的一层层传递关系
请求的处理流程和顺序需要程序运行时动态确定
