设计模式🎈
设计模式：是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。设计模式使代码开发真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。只有夯实地基搭好结构，才能盖好坚壮的大楼。也是我们迈向高级开发人员必经的一步。
总结：设计模式是设计经验的总结
🙈创建型：
- 单例模式(Singleton Pattern) 保证一个类仅有一个实例，并提供一个访问它的全局访问点
- 抽象工厂（Abstract Factory） 用于提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类．
- 建造者模式(Builder) 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示．
- 工厂方法模式（Factory Method) 定义一个用于创建对象接口，让子类决定将哪一个类实例化．Factory Method使一个类的实例化延迟到其子类．
- 原型模式(Prototype) 用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。
🙊结构型：
- 适配器模式（Adapter Pattern) 根据字面意思很好理解．将每一个类的接口转换成客户希望的另外一个接口．Ａｄａｐｔｅｒ使得原本接口不兼容而不能一起工作的那些类可以一起工作．
- 桥接模式（Bridge Pattern) 将抽象部分与它的实现部分分离，使他们都可以独立地变化．
- 装饰模式(Decorator Pattern) 动态的给一个对象添加一些额外的职责．就扩展性而言，Decorator模式比生成子类方式更为灵活．
- 组合模式(Composite Pattern) 将对象组合成树形结构以表示＂部分－整体＂的层次结构．Ｃｏｍｐｏｓｉｔｅ使得客户对单个对象和复合对象的使用具有一致性．
- 外观模式（Facade Pattern) 为系统中的一组接口提供一个一致的界面，ｆａｃａｄｅ模式定义了一个高层接口，这个接口使得这一子系统更加容易使用．
- 享元模式(Flyweight Pattern) 运用共享技术有效地支持大量细粒度的对象．
- 代理模式(Proxy Pattern) 为其他对象提供一个代理以控制对这个对象的访问。
🙉行为型：
- 模板方法(Template Method) 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
- 命令模式(Command Pattern) 将一个请求封装成一个对象，从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志，以及支持可取消操作．
- 迭代器模式(Iterator Pattern)提供一种方法顺序访问一个聚合对象中各个元素，而又不需要暴露该对象的内部表示．
- 观察者模式(Observer Pattern） 定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新。
- 解释器模式(Interpreter Pattern) 给定一个语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子．解释器模式需要解决的是，如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。比如正则表达式．
- 中介者模式(Mediator Pattern) 用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
- 职责链模式(Chain of Responsibility Pattern) 为解除请求的发送者和接收者之间耦合，而使用多个对象都有机会处理这个请求．将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它．
- 备忘录模式(Memento Pattern) 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。
- 策略模式(Strategy Pattern) 定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。
- 访问者模式(Visitor Pattern) 表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
- 状态模式(State Pattern)允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类．
六大设计原则🎉
(1）单一职责原则（Single Responsibility Principle）
定义：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
（2）里氏替换原则（Liskov Substitution Principle）
定义：主张使用抽象和多态 | 所有引用基类（父类）的地方必须能透明地使用其子类的对象。
1）如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。
2）只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。反过来，有子类出现的地方，父类未必就能适合
（3）依赖倒置原则（Dependence Inversion Principle，DIP）
定义：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象，其核心思想是：要面向接口编程，不要面向实现编程。
（4）接口隔离原则(Interface Segregation Principle, ISP)
定义：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
（5）迪米特法则(Law of Demeter, LOD)
定义：尽量减少类与类之间的联系
一个软件实体应当尽可能少地与其他实体发生相互作用。
（6）开闭原则(Open-Closed Principle, OCP)
定义：对扩展开放，对修改关闭
一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展