二十三种设计模式 和 六种设计原则
- 设计模式是在软件设计中经常用到的一些模式化的解决方案，它们提供了一套被广泛接受的、经过验证的解决问题的方法。
- 这些设计模式被分为三种类型：创建型、结构型和行为型。以下是常见的23种设计模式：
二十三种设计模式
创建型模式（Creational Patterns）：
1. 单例模式（Singleton Pattern）：
- 确保一个类只有一个实例，并提供全局访问点。
2. 工厂方法模式（Factory Method Pattern）：
- 定义一个用于创建对象的接口，但由子类决定实例化的类是哪一个。
3. 抽象工厂模式（Abstract Factory Pattern）：
- 提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。
4. 建造者模式（Builder Pattern）：
- 将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示。
5. 原型模式（Prototype Pattern）：
- 用于创建重复的对象，通过拷贝原型对象来创建新的对象。
结构型模式（Structural Patterns）：
6. 适配器模式（Adapter Pattern）：
- 将一个类的接口转换成客户希望的另外一个接口。
7.桥接模式（Bridge Pattern）：
- 将抽象部分与它的实现部分分离，使它们都可以独立地变化。
8.组合模式（Composite Pattern）：
- 将对象组合成树形结构以表示"部分-整体"的层次结构。
9.装饰器模式（Decorator Pattern）：
- 动态地给一个对象添加一些额外的职责，同时又不改变其结构。
10.外观模式（Facade Pattern）：
- 为子系统中的一组接口提供一个一致的界面，定义一个高层接口。
11.享元模式（Flyweight Pattern）：
- 通过共享技术来有效地支持大量细粒度对象的复用。
行为型模式（Behavioral Patterns）：
12. 责任链模式（Chain of Responsibility Pattern）：
- 使多个对象都有机会处理请求，将请求沿链传递，直到有一个对象处理它。
13. 命令模式（Command Pattern）：
- 将请求封装成一个对象，从而使用户可以用不同的请求对客户进行参数化。
14. 解释器模式（Interpreter Pattern）：
- 给定一个语言，定义它的文法的一种表示，并定义一个解释器。
15. 迭代器模式（Iterator Pattern）：
- 提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部的表示。
16. 中介者模式（Mediator Pattern）：
- 用一个中介对象来封装一系列的对象交互。
17. 备忘录模式（Memento Pattern）：
- 在不破坏封装的情况下，捕获对象的内部状态，并在对象之外保存这个状态。
18. 观察者模式（Observer Pattern）：
- 定义对象间的一种一对多的依赖关系，使得当一个对象状态改变时，所有依赖它的对象都会得到通知并自动更新。
19. 状态模式（State Pattern）：
- 允许对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。
20. 策略模式（Strategy Pattern）：
- 定义一系列算法，将每个算法封装起来，并使它们可以互换。
21. 模板方法模式（Template Method Pattern）：
- 定义一个操作中的算法的框架，将一些步骤延迟到子类中。
22. 访问者模式（Visitor Pattern）：
- 表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
23. 状态机模式（State Machine Pattern）：
- 定义对象的状态，并封装状态之间的转换。允许对象在其内部状态改变时改变它的行为。
这些设计模式提供了一种通用的解决方案，可以帮助开发人员更好地组织和设计他们的软件系统。在实际开发中，通常会根据具体情况选择合适的设计模式来解决问题。
6种设计原则
- 设计模式的使用通常与一些基本的设计原则相结合，这些原则有助于指导软件设计过程，提高代码的可维护性、灵活性和可扩展性。
- 其中最著名的是SOLID原则，这是由Robert C. Martin等人提出的一组五个设计原则。
- 此外，还有DRY（Don’t Repeat Yourself）原则。以下是这些原则的简要说明：
SOLID 原则：
1. 单一职责原则（Single Responsibility Principle - SRP）：
- 一个类应该只有一个引起它变化的原因。换句话说，一个类应该只有一个责任。
2.开放/封闭原则（Open/Closed Principle - OCP）：
- 软件实体（类、模块、函数等等）应该对扩展开放，对修改关闭。即通过扩展现有代码，而不是修改它，来满足新的需求。
3.里氏替换原则（Liskov Substitution Principle - LSP）：
- 子类型必须能够替换掉它们的基类型，而不影响程序的正确性。即，如果一个类型是基类，那么它的派生类应该能够替代基类而不影响程序的正确性。
4.接口隔离原则（Interface Segregation Principle - ISP）：
- 不应该强迫一个类去实现它用不到的接口。一个类应该不应该被强迫依赖它不使用的方法。
5.依赖倒置原则（Dependency Inversion Principle - DIP）：
- 高层模块不应该依赖于低层模块，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
DRY 原则：
6.不要重复自己原则（Don’t Repeat Yourself - DRY）：
- 避免在同一系统中重复相同的或类似的代码。重复代码会增加维护的难度，降低系统的灵活性。
这些原则提供了一系列指导方针，帮助开发人员创建更加灵活、可维护和可扩展的软件系统。在实际应用中，开发者通常会结合这些原则和设计模式，根据具体的场景和需求来进行设计和实现。