设计模式的核心原则

设计模式的核心原则是面向对象设计的指导性准则，旨在提高代码的可复用性、可维护性和灵活性。以下是 设计模式的七大核心原则 及其核心思想的总结：

1. 单一职责原则 (Single Responsibility Principle, SRP)

• 核心思想：一个类只负责一项职责（只因一个原因而变化）。
• 目标：高内聚、低耦合，降低类的复杂度。
• 实现方式：拆分职责，避免一个类处理多个不相关的功能。
• 示例：将 UserService 拆分为 UserRepository（数据存储）和 UserAuthService（登录验证）。

2. 开闭原则 (Open-Closed Principle, OCP)

• 核心思想：对扩展开放，对修改关闭。
• 目标：通过抽象和多态实现功能扩展，避免修改已有稳定代码。
• 实现方式：使用接口或抽象类定义规范，通过新增子类实现新功能。
• 示例：通过策略模式实现支付方式扩展（如新增支付宝支付时无需修改原有代码）。

3. 里氏替换原则 (Liskov Substitution Principle, LSP)

• 核心思想：子类必须能替换父类，且不影响程序正确性。
• 目标：确保继承关系的合理性，避免子类破坏父类的行为契约。
• 实现方式：子类需完全遵循父类的行为规范（如返回值、参数约束）。
• 示例：避免“正方形继承长方形”的问题（修改边长行为不一致）。

4. 接口隔离原则 (Interface Segregation Principle, ISP)

• 核心思想：客户端不应依赖不需要的接口，应拆分为更小、更具体的接口。
• 目标：减少接口与客户端的耦合，避免“胖接口”导致冗余。
• 实现方式：将大接口拆分为多个专用接口。
• 示例：将 Animal 接口拆分为 Flyable 和 Swimmable，避免鸟类被迫实现游泳方法。

5. 依赖倒置原则 (Dependency Inversion Principle, DIP)

• 核心思想：高层模块和低层模块都应依赖抽象（接口或抽象类），而非具体实现。
• 目标：解耦模块间的依赖关系，提高灵活性。
• 实现方式：通过依赖注入（DI）或抽象类实现依赖关系。
• 示例：Service 层依赖 Repository 接口，而非具体的 PostgreSQLRepository。

6. 迪米特法则 (Law of Demeter, LoD) / 最少知识原则

• 核心思想：一个对象应尽可能少地与其他对象交互（只与直接朋友通信）。
• 目标：降低类之间的耦合度，避免链式调用（如 a.getB().getC().doSomething()）。
• 实现方式：通过封装方法内部处理复杂交互。
• 示例：直接提供 a.doSomething()，内部处理对 B 和 C 的调用。

7. 合成复用原则 (Composite Reuse Principle, CRP)

• 核心思想：优先使用组合（has-a）而非继承（is-a）来复用代码。
• 目标：避免继承导致的强耦合，提高代码灵活性。
• 实现方式：通过组合对象实现功能扩展。
• 示例：用 List<T> 组合实现集合功能，而非继承 ArrayList。

SOLID 原则（五大核心原则）

SOLID 是上述七大原则中的五个核心原则的缩写，由 Robert C. Martin 提出：

1. SRP（单一职责原则）
2. OCP（开闭原则）
3. LSP（里氏替换原则）
4. ISP（接口隔离原则）
5. DIP（依赖倒置原则）

其他补充原则

• KISS 原则：保持代码简单直接（Keep It Simple, Stupid）。
• YAGNI 原则：不要过度设计（You Aren’t Gonna Need It）。
• DRY 原则：避免重复代码（Don’t Repeat Yourself）。

总结

这些原则共同构成设计模式的基础，帮助开发者应对复杂系统中的变化和扩展需求。实际应用中需根据场景灵活权衡，而非机械遵循。