设计原则总览

设计原则是设计模式的判断标准。模式告诉代码可以怎么组织，原则帮助判断为什么这样组织、什么时候应该抽象、什么时候应该保持简单。

设计原则不是硬性规则，而是控制变化成本的工程经验。实际使用时要先看问题：当前代码最容易因为哪类需求变更而受影响。

七个常用原则

原则	主要解决的问题	典型落地点
单一职责原则	一个模块承担太多变化原因	拆分服务、拆分处理器、分离业务与基础能力
开闭原则	新需求总要修改老代码	策略、工厂、责任链、插件化
里氏替换原则	继承后行为不兼容	正确设计父类契约和子类边界
依赖倒置原则	高层业务依赖底层细节	接口、端口、依赖注入
接口隔离原则	大接口迫使实现类依赖无关方法	小接口、角色接口、能力接口
迪米特法则	调用方知道太多内部结构	外观、封装、聚合根、应用服务
合成复用原则	继承层次膨胀	组合、委托、装饰器、策略

实操判断顺序

1. 先看职责是否混乱。一个类如果同时处理业务规则、持久化、通知、日志、配置读取，优先用单一职责原则拆边界。
2. 再看变化点是否集中。新增需求总改同一个核心类，通常违反开闭原则。
3. 再看依赖方向。高层业务如果直接依赖 SDK、数据库、消息队列客户端，通常需要依赖倒置。
4. 再看继承是否可靠。子类如果经常重写父类方法并抛异常，优先检查里氏替换。
5. 再看接口是否过大。实现类大量空方法、默认抛异常，通常需要接口隔离。
6. 再看对象关系是否穿透。到处出现 a.getB().getC()，通常需要迪米特法则。
7. 最后看复用方式。继承层次不断组合维度时，优先改成组合复用。

原则和模式的关系

原则	常见支撑模式
单一职责	策略、责任链、命令、外观
开闭原则	工厂方法、抽象工厂、策略、观察者、责任链
依赖倒置	工厂、适配器、桥接、代理
接口隔离	适配器、外观、桥接
迪米特法则	外观、中介者、代理
合成复用	装饰器、策略、组合、桥接

原则不是为了让代码变复杂，而是为了让变化更便宜。一个原则落地后，应该能回答两个问题：以后哪里会少改，哪里会更容易测试。