23种设计模式
创建类设计模式
# 单例模式、工厂模式（简单工厂模式、抽象工厂模式）、建造者模式、 原型模式
单例模式
# 总线：计算机各种功能部件或者设备之间传送数据、控制信号等信号的公共通信解决方案之一
# 单例：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
# 总线对象，就是一个单例，它仅有一个实例，各个线程对总线的访问只有一个全局访问点，即惟一的实例。
# 优点：
1、由于单例模式要求在全局内只有一个实例，因而可以节省比较多的内存空间；
2、全局只有一个接入点，可以更好地进行数据同步控制，避免多重占用；
3、单例可长驻内存，减少系统开销。
# 缺点：
1、单例模式的扩展是比较困难的；
2、赋于了单例以太多的职责，某种程度上违反单一职责原则;
3、单例模式是并发协作软件模块中需要最先完成的，因而其不利于测试；
4、单例模式在某种情况下会导致“资源瓶颈”。
# 应用：
1、生成全局惟一的序列号；
2、访问全局复用的惟一资源，如磁盘、总线等；
3、单个对象占用的资源过多，如数据库等；
4、系统全局统一管理，如Windows下的Task Manager；
5、网站计数器
简单工厂模式
# 工厂模式：一个用于创建对象的接口，让子类决定实例化哪个类。工厂方法使一个类的实例化延迟到其子类。
# 其产品类定义产品的公共属性和接口，工厂类定义产品实例化的“方式”。
# 简单工厂模式：省去将工厂实例化的过程，就是简单工厂模式
抽象工厂模式
# 抽象工厂模式：提供一个创建一系列相关或互相依赖对象的接口，而无需指定它们具体的类。
# 简单\抽象 工厂模式优点：
1、工厂模式巨有非常好的封装性，代码结构清晰；在抽象工厂模式中，其结构还可以随着需要进行更深或者更浅的抽象层级调整，非常灵活；
2、屏蔽产品类，使产品的被使用业务场景和产品的功能细节可以分而开发进行，是比较典型的解耦框架。
# 缺点：
1、工厂模式相对于直接生成实例过程要复杂一些，所以，在小项目中，可以不使用工厂模式；
2、抽象工厂模式中，产品类的扩展比较麻烦。
# 应用：
当系统实例要求比较灵活和可扩展时，可以考虑工厂模式或者抽象工厂模式实现。比如，在通信系统中，高层通信协议会很多样化，同时，上层协议依赖于下层协议，那么就可以对应建立对应层级的抽象工厂，根据不同的“产品需求”去生产定制的实例。
建造者模式
# 建造者模式：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
# 优点：
1、封装性好，用户可以不知道对象的内部构造和细节，就可以直接建造对象；
2、系统扩展容易；
3、建造者模式易于使用，非常灵活。在构造性的场景中很容易实现“流水线”；
4、便于控制细节。
# 缺点：
1、“加工工艺”对用户不透明。（封装的两面性）
# 应用：
1、目标对象由组件构成的场景中，很适合建造者模式。
2、在具体的场景中，对象内部接口需要根据不同的参数而调用顺序有所不同时，可以使用建造者模式。
原型模式
# 原型模式：用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象。
# 进行clone操作后，新对象的构造函数没有被二次执行，新对象的内容是从内存里直接拷贝的。
# 优点：
1、性能极佳，直接拷贝比在内存里直接新建实例节省不少的资源；
2、简化对象创建，同时避免了构造函数的约束，不受构造函数的限制直接复制对象，是优点，也有隐患。
# 缺点：
1、深拷贝和浅拷贝的使用需要事先考虑周到；
2、某些编程语言中，拷贝会影响到静态变量和静态函数的使用。
# 应用：
1、对象在修改过后，需要复制多份的场景。
2、需要优化资源的情况。如，需要在内存中创建非常多的实例，可以通过原型模式来减少资源消耗。此时，原型模式与工厂模式配合起来，不管在逻辑上还是结构上，都会达到不错的效果；
3、某些重复性的复杂工作不需要多次进行。如对于一个设备的访问权限，多个对象不用各申请一遍权限，由一个设备申请后，通过原型模式将权限交给可信赖的对象，既可以提升效率，又可以节约资源。
结构类设计模式
# 代理模式、装饰器模式、适配器模式、门面模式、组合模式、享元模式、桥梁模式
代理模式
装饰器模式
适配器模式
门面模式
组合模式
享元模式
桥梁模式
行为类设计模式
# 策略模式、责任链模式、命令模式、中介者模式、模板模式、迭代器模式、访问者模式、观察者模式、解释器模式、
# 备忘录模式、状态模式
策略模式
责任链模式
命令模式
中介者模式
模板模式
迭代器模式
访问者模式
观察者模式
解释器模式
备忘录模式
状态模式
设计模式的六大原则
# 单一职责原则、里氏替换原则、依赖倒转原则、接口隔离原则、迪米特法则、合成复用原则
总原则
开闭原则
# 开闭原则：对扩展开放，对修改关闭。
单一职责原则
# 单一职责原则：应该有且仅有一个原因引起类的变更。
里氏替换原则
# 里氏替换原则：任何基类可以出现的地方，子类一定可以出现。
# 子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互，子类不应该随便破坏它。
依赖倒转原则
# 依赖倒转原则：高层模块不应该依赖于低层模块，两者都应该依赖其抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
# 不与具体类交互，而与具体类的上层接口交互。
接口隔离原则
# 接口隔离原则：类间的依赖关系不应该建立一个大的接口，而应该建立其最小的接口，即客户端不应该依赖那些它不需要的接口。
# 接口隔离原则和单一职责原则一样，涉及到粒度的问题，解决粒度大小，同样依赖于具体的业务场景，
迪米特法则
# 迪米特法则：一个对象应该对其它对象有最少的了解。
# 五大特征：
1.当前对象本身（self）；
2.以参量形式传入到当前对象方法中的对象；
3.当前对象的实例变量直接引用的对象；
4.当前对象的实例变量如果是一个聚集，那么聚集中的元素也都是朋友；
5.当前对象所创建的对象。
合成复用原则
# 合成复用原则：尽量首先使用合成/聚合的方式，而不是使用继承。
深入了解：https://www.cnblogs.com/liuqingzheng/p/10038958.html#_label2
https://www.cnblogs.com/geek6/p/3951677.html
