SOLID原则
面向对象设计（OOD）中五个核心原则的缩写，由 Robert C. Martin（ Uncle Uncle Bob ）提出，旨在核心目标是降低耦合、提高内聚，指导开发者设计出更清晰、灵活、可维护的代码。
SRP
Single Responsibility Principle, 单一职责原则。
定义：一个类应该只有一个引起它变化的原因（即一个类只负责一项职责）。
核心：避免类承担过多职责，否则职责间的耦合会导致修改一个职责时影响其他职责，降低代码可维护性。
示例：一个 User 类不应同时负责用户数据存储（如数据库操作）和用户界面展示，应拆分为 User（数据模型）、UserRepository（数据存储）、UserView（界面展示）三个类。
OCP
Open/Closed Principle, 开放/封闭原则。
定义：软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。
核心：当需求变化时，应通过新增代码（如扩展类、实现新接口）来满足，而非修改已有稳定代码，以减少风险。
实现：通过抽象（接口或抽象类）定义稳定的规范，具体实现类依赖于抽象，新增功能时只需添加新的实现类。
LSP
Liskov Substitution Principle, 里氏替换原则。
定义：子类对象必须能够替换其父类对象，且替换后不影响程序的正确性（即子类应遵循父类的行为契约）。
核心：确保继承关系的合理性，子类不能破坏父类的预期行为（如前置条件不能更强，后置条件不能更弱）。
反例：正方形继承自长方形，重写 SetWidth 和 SetHeight 时强制宽高相等，会导致使用长方形的代码逻辑出错（违反里氏替换）。
ISP
Interface Segregation Principle, 接口隔离原则。
定义：客户端不应被迫依赖它不需要的接口（即接口应最小化，避免 “胖接口”）。
核心：将庞大的接口拆分为多个专用接口，让客户端只依赖自己需要的接口，减少不必要的耦合。
示例：一个 IMachine 接口若包含 Print()、Scan()、Fax() 方法，对于仅需打印功能的客户端（如打印机），应拆分为 IPrinter、IScanner、IFax 三个独立接口。
DIP
Dependency Inversion Principle, 依赖倒置原则。
定义：高层模块不应依赖低层模块，两者都应依赖抽象；抽象不应依赖细节，细节应依赖抽象。
核心：通过抽象（接口或抽象类）隔离高层与低层模块，降低直接依赖，提高系统灵活性。
实现：使用依赖注入（DI）、工厂模式等，使高层模块依赖抽象接口，低层模块实现接口。
示例：业务逻辑层（高层）不应直接依赖数据库访问层（低层），而应依赖 IDataRepository 抽象接口，数据库层实现该接口。
继承&实现
比较三种设计方式：
- 多个类实现同一接口；
- 一个具体基类实现接口，其他类继承该基类；
- 基于第二点，基类为抽象类；
推荐优先级通常是：3 > 1 > 2。
核心原则：优先通过接口定义规范，通过抽象类封装共性，通过继承实现差异，避免具体类的强耦合。
多个类实现接口
推荐场景：无明显共性逻辑（或共性极少），各自的实现差异较大。
优点：
- 完全遵循 “接口隔离原则”，每个类只依赖自己需要的接口方法，避免继承带来的耦合。
- 灵活性高，类之间独立，修改一个类的实现不会影响其他类。
- 符合 “组合优于继承” 的设计思想，减少继承层次的复杂性。
缺点： - 若类之间存在重复逻辑（如接口中某个方法的实现完全相同），会导致代码冗余，维护成本增加。
具体基类实现接口
不推荐，除非场景极其简单且确定未来不会扩展。
缺点：
- 具体基类的实现会被所有子类继承，若子类需要修改基类的方法，可能违反 “里氏替换原则”（子类替换父类后可能破坏原有逻辑）。
- 基类的任何修改（即使是优化）都会直接影响所有子类，耦合度极高，扩展性差。
- 子类可能被迫继承不需要的基类方法（违反 “接口隔离原则”），导致逻辑混乱。
抽象基类实现接口
推荐场景：多个类实现接口时，存在共性逻辑（可复用），但同时有各自的差异逻辑（需子类自定义）。
优点：
- 兼顾复用与灵活性：抽象基类可实现接口中 “共性方法”（减少重复代码），同时将 “差异方法” 定义为抽象方法（强制子类实现，保证接口规范）。
- 符合里氏替换原则：抽象基类不能实例化，子类必须实现抽象部分，确保替换父类后逻辑一致。
- 平衡抽象与具体：既通过接口定义了规范（对扩展开放），又通过抽象类封装了稳定的共性逻辑（对修改关闭）。
