所谓的设计模式，只是在OOP（ 面向对象程序设计）领域内，一些前人总结出来的最佳工作实践而已，可以说是一种拆箱即用的工作模版。
学习设计模式的坏处：
- 经典的23种设计模式，涵盖的场景很多，学习成本高；
- 很多模式相互交叉，相互可以转换，让人难以分辨。学习设计模式是为了解决业务问题，但是本末倒置，却钻牛角尖去研究设计模式里面的奥妙了；
不要为了设计而设计，这种行为就行一个小孩在大人衣柜前胡乱的穿搭着大人的西装。
设计模式，应该是在工作有需求之后才来学习（不要担心来不及），累积了很多场景在心中之后，一通百通。而不是还未熟悉编程、业务设计就开始钻研这个，有点本末倒置。
六大设计原则 + 合成复用原则
程序设计领域的设计模式的六大设计原则 + 合成复用原则（Composite Reuse Principle） ，都是一些很泛的思想（它们既可以指这个，也可以代指那个），无法生搬硬套，无法做到很具体的指导，我的建议是，有空多看几遍、多思考看看怎么能运用在实际项目中，在未来时保佑自己在设计程序时能联想到即可。
矛盾性的思考：
有时在面对一个复杂需求时，可能会面临满足了这个原则就会矛盾另一个原则的情况，这种就得做必要的取舍。
关于记忆的一些个人见解：
设计模式、设计原则...，我觉得都是不要去记忆它，而是通过你工作中的项目代码、网上好的项目代码，去做归纳总结、去发现一些特征。自己不断的总结提炼，我觉得这样才会形成自己的软件设计原则，硬背下来的，还是不灵活的。
Global Diagram
依赖倒置原则（依赖抽象接口，而不是具体对象）
- 它强调了高层次模块不应该依赖于低层次模块，而是应该依赖于抽象（接口）。这个原则有助于降低类之间的耦合度，提高系统的可维护性和可复用性。
- 依赖倒置原则要求我们将具体的实现类通过接口或者抽象类进行抽象，以便高层次模块不需要知道低层次模块的具体实现细节。这样，当低层次模块发生改变时，高层次模块不需要进行任何修改，只需要重新配置依赖关系即可。
单一职责原则（类、接口、方法）
- 一个类（接口、方法）只承担一个职责；
- 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响；
开闭原则 （扩展开放，修改关闭）
- 对已经完成的程序来说，最佳的维护状态是，只对扩展开放，对修改关闭；
里氏替换原则（基类和子类之间的关系）
- 这个原则的核心思想是，如果一个类继承自另一个类，那么子类可以替换父类进行任何操作，前提是不能违反程序的原始行为。这要求子类的方法实现不能违背父类的规范和约束；
- 子类可以扩展父类的功能，但不能改变父类原有的功能；
- 只要父类出现的地方，子类就也可以出现，而且替换为子类后不会出现任何错误；
接口隔离原则（接口按照功能细分）
- 要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法；
- 核心就是：不要让用户、接口实现者去实现不相关的功能；
- 这个和单一职责原则有点重复；
最少知道原则 （类与类之间的亲疏关系）
- 最小化权限；
合成复用原则（Composite Reuse Principle）
- 尽量使用对象组合/聚合，而不是继承关系达到软件复用的目的；
- 合成或聚合可以将已有对象纳入到新对象中，使之成为新对象的一部分，因此新对象可以调用已有对象的功能；
有些编程语言就没有继承概念，只有组合、复用概念，各自的好坏有待辩证吧。
三大类设计模式
设计模式是为解决特定设计问题而创建的通用解决方案。它们被分为三大类：创建型模式、结构型模式和行为型模式。以下是每一类中的常见设计模式：
1. 创建型模式（Creational Patterns）
创建型模式主要关注对象的创建过程，确保对象创建的过程是独立于系统中的具体实现。常见的创建型模式包括：
- 单例模式（Singleton Pattern）：确保一个类只有一个实例，并提供全局访问点。
- 工厂方法模式（Factory Method Pattern）：定义一个用于创建对象的接口，但让子类决定实例化哪个类。
- 抽象工厂模式（Abstract Factory Pattern）：提供一个创建一系列相关或相互依赖对象的接口，而无需指定具体类。
- 建造者模式（Builder Pattern）：将一个复杂对象的构建过程与它的表示分离，使得同样的构建过程可以创建不同的表示。
- 原型模式（Prototype Pattern）：通过复制现有的对象来创建新对象，而不是通过实例化类。
2. 结构型模式（Structural Patterns）
这个结构和数据结构不是一码事。
结构型模式主要关注如何将类或对象组合在一起以形成更大的结构。它们帮助确保系统的各个部分能够以有效的方式组合。常见的结构型模式包括：
- 适配器模式（Adapter Pattern）：将一个类的接口转换成客户端所期望的另一个接口，使得不兼容的接口可以一起工作。
- 桥接模式（Bridge Pattern）：将抽象部分与实现部分分离，使得它们可以独立变化。
- 组合模式（Composite Pattern）：将对象组合成树形结构以表示“部分-整体”的层次结构，使得客户端对单个对象和组合对象的使用具有一致性。
- 装饰器模式（Decorator Pattern）：动态地给一个对象添加一些额外的职责，而不会影响到其他对象。
- 外观模式（Facade Pattern）：为子系统中的一组接口提供一个统一的高层接口，使得子系统更易使用。
- 享元模式（Flyweight Pattern）：通过共享对象来支持大量细粒度的对象，以减少内存使用和提高性能。
- 代理模式（Proxy Pattern）：为其他对象提供一种代理以控制对这个对象的访问。
3. 行为型模式（Behavioral Patterns）
行为型模式主要关注对象和类之间的职责分配，如何通过协调对象之间的行为来实现复杂的行为。常见的行为型模式包括：
- 责任链模式（Chain of Responsibility Pattern）：将请求沿着处理链传递，直到有对象处理它为止。
- 命令模式（Command Pattern）：将请求封装为一个对象，以便使用不同的请求、排队请求和日志请求，以及支持可撤销操作。
- 解释器模式（Interpreter Pattern）：为语言的语法定义一个表示，并定义一个解释器来解释这些语法。
- 迭代器模式（Iterator Pattern）：提供一种方法顺序访问一个聚合对象中的各个元素，而不暴露该对象的内部表示。
- 中介者模式（Mediator Pattern）：定义一个对象来封装一系列的对象交互，使得对象之间的耦合松散。
- 备忘录模式（Memento Pattern）：在不暴露对象内部状态的情况下，捕获对象的内部状态，以便在以后恢复。
- 观察者模式（Observer Pattern）：定义对象间的一种一对多依赖关系，使得当一个对象改变状态时，其所有依赖者都会收到通知并自动更新。
- 状态模式（State Pattern）：允许对象在内部状态改变时改变它的行为，对象将表现出不同的行为。
- 策略模式（Strategy Pattern）：定义一系列算法，把它们一个个封装起来，并使它们可以互换。
- 模板方法模式（Template Method Pattern）：定义一个操作中的算法的骨架，将一些步骤延迟到子类中，以便子类可以重新定义算法的某些特定步骤。
- 访问者模式（Visitor Pattern）：定义一个操作上的新方法而不改变操作的结构，使得你可以在不修改元素的类的前提下定义新的操作。
这些设计模式可以帮助开发者创建更灵活、可维护和可扩展的系统，解决不同的软件设计问题。
