6大设计原则与23种设计模式

Java的六大设计原则

1. 开闭原则（Open-Closed Principle）：一个软件实体（如类、模块、函数）应该对扩展开放，对修改关闭。也就是说，软件实体应该可以在不修改的前提下进行扩展。
2. 里氏替换原则（Liskov Substitution Principle）：所有引用基类（父类）的地方必须能透明地使用其子类的对象。这意味着子类必须能够替换掉其父类，并且程序的行为没有变化。
3. 依赖倒置原则（Dependency Inversion Principle）：高层模块不应该依赖低层模块，它们都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。这意味着我们应该面向接口编程，而不是面向实现编程。
4. 接口隔离原则（Interface Segregation Principle）：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。这意味着我们应该将大的接口拆分成更小的和更具体的接口，以便客户端只需要知道它们感兴趣的方法。
5. 迪米特法则（Law of Demeter）：一个对象应该对其他对象保持最少的了解。也就是说，一个类应该尽量降低其成员变量、方法的可见性（尽量私有），对外提供公共的方法。这样，当一个对象需要改变时，就会尽量少的影响其他的对象。
6. 单一职责原则（Single Responsibility Principle）：一个类应该只有一个引起变化的原因。这意味着我们应该避免设计一个大而全的类，而是应该将功能细化到不同的类中，每个类只负责一个特定的功能。

23种设计模式

1. 单例模式（Singleton Pattern）

定义：确保一个类只有一个实例，并提供一个全局访问点。

特点：全局只有一个访问点，构造方法私有化，线程安全。

应用场景：数据库连接池、日志记录、缓存系统等。

优点：节省资源，避免频繁创建和销毁对象。

缺点：可能导致全局状态，不利于扩展和测试。

2. 工厂方法模式（Factory Method Pattern）

定义：定义一个用于创建对象的接口，让子类决定实例化哪一个类。

特点：延迟实例化到子类，解耦客户端与具体实现类。

应用场景：提供创建对象的灵活性，允许在不改变代码的情况下更换创建逻辑。

优点：降低耦合度，提高可扩展性。

缺点：增加类的数量。

3. 抽象工厂模式（Abstract Factory Pattern）

定义：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。

特点：一组相互关联的工厂方法，共同约束产品族。

应用场景：创建不同的产品对象，客户端应使用不同的具体工厂。

优点：客户端与具体实现解耦，易于扩展产品族。

缺点：如果新增产品族，改动极大。

4. 建造者模式（Builder Pattern）

定义：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

特点：构建过程与表示分离，分步骤构建对象。

应用场景：创建复杂的对象，需要自定义不同的配置或属性。

优点：灵活度高，易于扩展。

缺点：如果产品类内部变化复杂，可能会增加很多建造者类。

5. 原型模式（Prototype Pattern）

定义：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

特点：通过复制现有对象来创建新对象。

应用场景：创建大量相似对象时，避免重复创建的开销。

优点：性能良好，提高效率。

缺点：需要为每个类配备一个克隆方法。

6. 适配器模式（Adapter Pattern）

定义：将一个类的接口转换成客户端所期望的另一个接口形式，使得原本由于接口不兼容而无法一起工作的那些类能一起工作。

特点：将两个不兼容的接口转换为可兼容的接口。

应用场景：当现有接口与需要使用的接口不兼容时，可以使用适配器模式进行转换。

优点：提高已有类的复用性，减少代码冗余。

缺点：过多使用适配器会使系统变得复杂，不易于理解。

7. 桥接模式（Bridge Pattern）

定义：将抽象部分与实现部分分离，使它们都可以独立地变化。

特点：抽象与实现解耦，可以独立变化。

应用场景：当某个类存在多个变化维度，并且这些变化维度相互独立时，可以使用桥接模式。

优点：提高系统的可扩展性，符合开闭原则。

缺点：增加了系统的理解和设计难度。

8. 组合模式（Composite Pattern）

定义：将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。

特点：树形结构，表示部分与整体的关系。

应用场景：当需要表示对象的部分与整体的关系时，可以使用组合模式。

优点：提高了代码的复用性，使得客户端对单个对象和组合对象的使用具有一致性。

缺点：使得设计更加复杂，客户端需要知道对象的层次结构。

9. 装饰器模式（Decorator Pattern）

定义：动态地给一个对象添加一些额外的职责，就增加功能来说，装饰器模式相比生成子类更为灵活。

特点：动态添加职责，开闭原则。

应用场景：当需要动态地给一个对象增加功能时，可以使用装饰器模式。

优点：灵活度高，易于扩展。

缺点：如果过度使用装饰器模式，可能会导致产生过多的具体装饰类。

10. 外观模式（Facade Pattern）

定义：为子系统中的一组接口提供一个一致的界面，使得子系统更加容易使用。

特点：简化接口，隐藏子系统复杂性。

应用场景：当系统比较复杂，客户端需要简化接口时，可以使用外观模式。

优点：降低了客户端与子系统之间的耦合度，使得子系统更加易于使用和维护。

缺点：如果设计不当，可能会导致客户端过于依赖外观类，使得子系统难以改变。

11. 观察者模式（Observer Pattern）

定义：定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。当主题对象状态发生改变时，它的所有依赖者（观察者）都会收到通知并自动更新。

特点：主题与观察者之间松耦合，主题只知道观察者实现了某个接口，不需要知道观察者的具体实现。

应用场景：当需要在某个对象状态改变时通知其他对象时，可以使用观察者模式。例如，事件处理系统、GUI编程等。

优点：支持广播通信，减少对象之间的耦合度，使得系统更加易于扩展和维护。

缺点：如果观察者过多，可能会影响到性能。

12. 状态模式（State Pattern）

定义：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。

特点：将状态封装为对象，状态切换由状态对象自行管理。

应用场景：当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时，可以使用状态模式。例如，游戏角色的状态切换（行走、奔跑、攻击等）。

优点：封装了转换规则，将行为划分到不同的状态对象中，使得代码更加清晰、易于维护。

缺点：如果状态过多，可能会导致系统变得复杂。

13. 策略模式（Strategy Pattern）

定义：定义了一系列的算法，并将每一个算法封装起来，使它们可以互相替换。策略模式使得算法可以独立于使用它的客户端变化。

特点：策略与客户端分离，策略之间可以相互替换。

应用场景：当需要在不同的场景下使用不同的算法时，可以使用策略模式。例如，排序算法的选择、支付方式的切换等。

优点：提高了代码的复用性和可维护性，降低了客户端与具体策略之间的耦合度。

缺点：如果策略过多，可能会增加系统的复杂性。

14. 模板方法模式（Template Method Pattern）

定义：定义一个操作中的算法的框架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重新定义该算法的某些特定步骤。

特点：模板方法定义了算法的骨架，具体实现由子类完成。

应用场景：当需要在多个类中实现相同的算法逻辑，但算法中的某些步骤在不同的类中实现不同时，可以使用模板方法模式。例如，文件读取的模板（不同的文件格式有不同的读取方式）。

优点：提高了代码的复用性和可维护性，使得子类可以方便地扩展和修改算法。

缺点：如果算法中的某些步骤不能被子类覆盖，可能会导致算法的不灵活性。

15. 访问者模式（Visitor Pattern）

定义：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

特点：将操作与数据结构分离，使得可以在不修改数据结构的前提下增加新的操作。

应用场景：当需要在不修改现有类的情况下增加新的操作时，可以使用访问者模式。例如，对不同的数据结构进行遍历和打印。

优点：提高了系统的可扩展性和灵活性，使得在不修改现有类的情况下可以方便地增加新的操作。

缺点：如果数据结构过于复杂，可能会导致访问者类的数量过多，使得系统变得复杂。

16. 解释器模式（Interpreter Pattern）

定义：给定一个语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。

特点：将一种特定类型的问题的表达式，通过一种解释器来解析，并得出表达式所代表的具体含义。

应用场景：当需要解析某种特定语法或表达式时，可以使用解释器模式。例如，编译器、表达式求值等。

优点：可扩展性好，容易实现新的解释表达式。

缺点：对于复杂的文法，解释器模式可能会产生过多的类文件，导致系统难以管理和维护。

17. 迭代器模式（Iterator Pattern）

定义：提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。

特点：遍历者模式是为遍历集合内的元素而设计的，它使得集合的遍历与集合的内部结构无关。

应用场景：当需要遍历某个聚合对象（如列表、集合等）时，可以使用迭代器模式。

优点：简化了聚合类接口，使得代码更加清晰，同时支持以不同的方式遍历聚合对象。

缺点：如果聚合对象比较大，迭代器模式的实现可能会占用较多的内存。

18. 中介者模式（Mediator Pattern）

定义：用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

特点：降低了系统中对象之间的耦合度，使得对象之间不需要直接交互，而是通过中介者进行交互。

应用场景：当多个对象之间存在复杂的交互关系时，可以使用中介者模式来简化它们之间的交互。例如，聊天室系统、MVC框架中的控制器等。

优点：降低了对象之间的耦合度，使得系统更加易于维护和扩展。

缺点：如果中介者处理不当，可能会导致系统变得复杂和难以理解。

19. 备忘录模式（Memento Pattern）

定义：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。

特点：保存了对象的内部状态，使得对象可以回到之前的状态。

应用场景：当需要保存和恢复对象的状态时，可以使用备忘录模式。例如，撤销操作、游戏存档等。

优点：提供了对对象状态的保存和恢复功能，使得对象可以回到之前的状态。

缺点：如果对象的状态过多，可能会占用大量的内存空间。

20. 原型模式（Prototype Pattern）

定义：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

特点：通过复制现有对象来创建新对象，而不是通过实例化类来创建新对象。

应用场景：当需要创建大量相似对象时，可以使用原型模式来快速创建对象。例如，对象的深拷贝和浅拷贝等。

优点：提高了对象的创建效率，减少了对象的创建时间。

缺点：如果对象之间存在复杂的关联关系，可能会导致深拷贝时出现问题。

21. 代理模式（Proxy Pattern）

定义：为其他对象提供一个代理以控制对这个对象的访问。

特点：代理对象与被代理对象具有相同的接口，客户端通过代理对象间接地访问被代理对象。

应用场景：当需要在访问对象之前或之后添加一些额外的操作时，可以使用代理模式。例如，远程代理、安全代理等。

优点*：在客户端与被代理对象之间增加了一层控制层，使得客户端可以更加灵活地控制对被代理对象的访问。

缺点：增加了系统的复杂性，需要维护代理对象和被代理对象之间的对应关系。

22. 职责链模式（Chain of Responsibility Pattern）

定义：避免请求发送者与接收者耦合在一起，让多个对象都有可能成为请求的接收者，将这些对象连接成一条链，并且沿着这条链传递该请求，直到有对象处理它为止。

特点：将请求的处理者组织成一条链，沿着链传递请求，直到找到能够处理请求的对象。

应用场景：当需要按照一定顺序处理多个请求时，可以使用职责链模式。例如，异常处理、日志记录等。

优点：降低了请求发送者与接收者之间的耦合度，使得系统更加易于扩展和维护。

缺点：如果链中的节点过多，可能会导致请求处理时间过长或无法找到能够处理请求的对象。

23. 命令模式（Command Pattern）

定义：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。

特点：

1. 封装请求：将请求作为一个对象进行封装，以便在请求队列中传递、存储和调用。
2. 解耦：请求发送者和接收者之间通过命令对象进行解耦，使得发送者无需知道接收者的具体实现。
3. 可撤销和重做：支持对命令的撤销和重做操作。

应用场景：

1. GUI中的按钮点击事件：每个按钮都关联一个命令对象，当按钮被点击时，就执行该命令对象。
2. 批量操作：将多个操作封装为命令对象，并放入队列中，然后依次执行这些命令对象。
3. 日志记录：在执行命令对象前后，可以记录日志信息，以便进行后续的分析和审计。

优点：

1. 降低耦合度：通过引入命令对象，使得请求发送者和接收者之间解耦。
2. 扩展性好：可以轻松地添加新的命令，只需要实现命令接口即可。
3. 支持撤销和重做：可以方便地实现命令的撤销和重做功能。

缺点：

1. 增加系统复杂性：由于引入了命令对象，可能会增加系统的复杂性和维护成本。
2. 性能开销：在执行命令时，可能需要额外的内存来存储命令对象，从而增加性能开销。

总的来说，命令模式是一种非常有用的设计模式，它可以帮助我们实现请求的封装、解耦、撤销和重做等功能，提高系统的可扩展性和可维护性。但是，在使用命令模式时，我们也需要注意其可能带来的系统复杂性和性能开销问题。