我入行这些年，面试过不少人，也带过不少新人。每次聊到“面向对象的六大原则”，大部分人的反应都是：能背出名字，单一职责、开闭、里氏替换、接口隔离、依赖倒置、迪米特法则，然后呢？然后就没有然后了。大家把六大原则当成八股文在背，可真到了写代码的时候，该咋写还咋写，改一处崩一片的烂代码照样满天飞。
这六大原则其实不是拿来背的，是拿来用的。我见过太多因为违反这些原则导致的“血案”：一个类两三千行，改一个需求要在十几个方法里翻来翻去；一个基类被十几个子类继承，结果为了兼容某个子类，基类的判断逻辑越堆越厚；模块之间互相new来new去，想做个单元测试都得先把整个系统跑起来。这些问题的根源，说穿了就是没把六大原则当回事。
这篇文章不讲虚的，我把每一条原则从“它到底在说什么”到“实际代码里怎么用”，再到“我踩过的坑”，一次性讲透。不管你是刚入行的新人，还是写了两三年代码想提升的老手，这篇都值得花二十分钟看完。看完了你会发现，这些原则不是束缚你的条条框框，而是让你少加班、少背锅的护身符。
1. 六大原则到底在解决什么问题
1.1 从一段“能跑的烂代码”说起
先看一段我真实重构过的代码。某公司一个订单模块，最早只有下单功能，后来需求不断叠加，类开始膨胀。我接手时大概是这个状态：
public class OrderService { public void createOrder(Order order) { // 1. 校验订单 if (order.getAmount() < 0) { throw new IllegalArgumentException("金额非法"); } if (order.getUserId() == null) { throw new IllegalArgumentException("用户不存在"); } // 2. 计算优惠 double discount = 0; if (order.getCouponCode() != null) { discount = order.getAmount() * 0.1; } // 3. 保存订单 saveToDb(order); // 4. 发送通知 sendSms(order.getUserPhone(), "您有一个新订单"); // 5. 记录日志 log(order); } public void cancelOrder(String orderId) { // 查询订单 Order order = findFromDb(orderId); if (order == null) { throw new IllegalArgumentException("订单不存在"); } // 更新状态 order.setStatus(OrderStatus.CANCELLED); saveToDb(order); // 退款 refund(order); // 发通知 sendSms(order.getUserPhone(), "您的订单已取消"); } private void saveToDb(Order order) { /* 数据库操作 */ } private void sendSms(String phone, String msg) { /* 短信操作 */ } private void refund(Order order) { /* 退款逻辑 */ } private void log(Order order) { /* 日志操作 */ } }这段代码能跑，甚至跑得挺稳。但问题在哪儿？你细品：订单校验、优惠计算、持久化、短信通知、日志，五种职责全塞在一个类里。下周你说要加个邮件通知，好，改这个类；说优惠规则要改成满减，好，改这个类；说日志要上报到某个监控平台，好，还改这个类。这个类会越改越大，越改越容易出错，直到某一天你改优惠规则的时候，不小心把短信接口的入参改错了，线上事故就这样发生了。
六大原则的第一条，单一职责原则，就是冲着这种问题去的。
1.2 原则之间的“配合关系”比单条更重要
很多人学六大原则是一个一个分开学的，这是最大的误区。单一职责告诉你一个类只管一件事，但你管好后发现，类变多了，类与类之间怎么协作？于是有了依赖倒置原则，告诉你要面向抽象编程，别直接依赖具体实现。接口多了，怎么划分才合理？于是有了接口隔离原则。继承体系怎么设计才能让子类安全替换父类？于是有了里氏替换原则。系统之间怎么才能减少耦合？于是有了迪米特法则。而这一切的最终目标，是让系统面对需求变化时“对修改关闭、对扩展开放”，也就是开闭原则。
所以我的理解是：**开闭原则是总目标，其余五条是手段。**单一职责让你的类足够小，改起来影响面小；依赖倒置让你的模块之间足够松，加新实现不用动旧代码；里氏替换让你的继承体系足够稳，换实现不会炸。五条手段各自从不同角度发力，共同支撑起“拥抱变化”这个目标。
记住这个关系再往下看，你会发现自己以前很多困惑，其实是因为把原则当成了孤立的教条。
2. 单一职责与开闭原则：最核心也最容易被带偏
2.1 单一职责的本质是“变化原因”
先纠正一个常见误解：单一职责不是“一个类只做一件事”。这句话听起来对，但没法指导实践。一个订单类，你说它是只管订单数据，还是管订单的创建、取消、查询？真要按“一件事”划分，一个类可能只剩一个方法了，这显然不合理。
我比较认可的说法是：**一个类应该有且仅有一个引起它变化的原因。**你要是实在不好判断，就问自己一个问题：如果需求变化，修改这个类的原因可能有哪些？如果答案超过一个，说明职责不单一。
举个例子。某个报表类，它既负责从数据库查询数据，又负责把数据格式化成图表能用的结构，还负责生成图片文件。这时候改查询逻辑要动它，改图表配色要动它，改文件格式还要动它。三个变化原因，就得拆。数据查询做成一个类，数据转换做一个类，图片生成做一个类。改配色的时候你不会碰到查询代码，焦虑感直接减半。
拆完之后类多了，可能有人会觉得“类爆炸”也不好吧？这个问题要辩证看。如果一个类本身就很小、很清晰，那拆出来几个类完全没问题。真正的类爆炸，往往是你把拆分的粒度搞错了，比如把方法级别的逻辑硬拆成类，那确实是过度设计。一个合理的判断标准是：拆出来的每个类，都能用一句话说清楚它的职责，而且这句话里没有“和”字。
2.2 开闭原则：把“改”变成“加”
开闭原则是六大原则里最理想化的一条：对扩展开放，对修改关闭。意思是，系统加新功能的时候，应该尽量不修改已有代码，而是通过增加新代码来实现。
说得玄乎，其实核心就一句话：**把容易变化的部分抽象出来，让新需求通过实现接口、继承抽象类来接入。**最常见的落地手法就是策略模式。
举个例子。某消息推送模块，最早只支持短信。按错误写法，你会这样：
public class MessageService { public void send(String type, String content) { if ("sms".equals(type)) { sendSms(content); } else if ("email".equals(type)) { sendEmail(content); } } }代码很坦诚，但很脆弱。下个月要加微信推送，你打开这个类，再补一个else if。加了三次之后，这个方法的圈复杂度已经到了看不懂的地步，而且你想测试某条分支，得把所有分支的依赖全部构造出来。
按开闭原则的思路，应该先抽象一个消息发送接口：
public interface MessageSender { void send(String content); boolean supports(String type); }短信、邮件、微信分别实现这个接口，在配置或工厂里注册。以后加新渠道，新建一个类实现接口就算完事，原有代码一行都不用改。这就是“对修改关闭”的含义——不是不允许修改，而是把修改关在小范围内，尽可能不影响稳定代码。
但我要提醒一句：不要矫枉过正。刚起步的项目，未来需求还没影儿呢，你就把所有地方都抽象成接口加工厂，那叫过度设计。开闭原则的正确用法，是在需求变化出现第二次的时候再动手抽象。第一次变化，说明这是真实需求，值得抽象；第二次变化，说明这个点可能还会继续变，抽象出来能省下后面的功夫。第一次就抽象，多半是拍脑袋。
2.3 两个原则配合落地的一个小例子
我把前两条放在一起说，是因为它们经常一起出现。我曾经重构过一个用户注册模块，原始代码长这样：一个注册方法里，校验用户名、校验密码强度、校验邮箱格式、写数据库、发欢迎邮件、发短信验证码，六件事全在一个方法里。这就是典型的单一职责和开闭原则同时被违反。
重构思路是这样的：先把校验逻辑抽成一个UserValidator，把通知逻辑抽成NotificationService（内部再按开闭原则用策略模式支持邮件、短信、站内信），注册主流程只保留“组装请求、校验、落库、发通知”这几个步骤。改完的效果是：改密码校验规则，只动UserValidator；加一个新的通知渠道，只动NotificationService；主流程的注册方法基本不再变了。
那一次重构之后，我养成了一个习惯：写新代码之前，先问自己一句，这个方法里有没有两个以上“变化方向”的代码？有就拆。这个习惯帮我少加了很多班。
3. 里氏替换与接口隔离：继承体系里的两道紧箍咒
3.1 里氏替换：子类别给父类“挖坑”
里氏替换原则的官方定义有点绕：所有引用基类的地方，必须能透明地使用其子类对象。说白了，子类可以扩展父类的能力，但不能改变父类已有的行为约定。
最容易理解的例子是那个经典的“正方形不是长方形”的问题。假设你有一个Rectangle类，有setWidth、setHeight、getArea方法。你继承出一个Square类，重写了setWidth让宽高同时变化，以保证正方形约束。这时候，任何依赖Rectangle的代码，比如一个“把宽度设为5、高度设为4、然后断言面积是20”的测试，在传入Square对象时就会爆炸，因为面积变成了16。正方形在数学上是长方形的子类，但在代码里，它破坏了父类的行为约定，就不该继承Rectangle。
我在实际项目里遇到的里氏替换问题，比这个隐晦得多。最常见的一种：基类定义了一个getStatus()方法，返回枚举类型。某个子类觉得要表达更细的状态，比如增加一个“处理中但部分成功”的状态，于是它改了返回值类型，或者在原枚举上动了手脚。结果凡是遍历基类列表、在switch里判断状态的代码，全部开始出现偶发bug。这就是典型的子类悄悄改变父类约定。
避免这种问题，我的经验是三条：第一，子类重写父类方法时，前置条件不能加强——父类说“传正数就行”，子类不能要求“必须传大于10的数”；第二，后置条件不能削弱——父类承诺“返回值永远非空”，子类不能偷偷返回null；第三，父类没有抛出的异常，子类尽量不要新增受检异常。这三条是里氏替换的实操版，比背定义有用得多。
另外一个偏方：如果你发现一个子类重写了父类的大部分方法，而且重写后的行为跟父类几乎没有关联，那大概率你们不是继承关系。用组合替代继承，往往更干净。
3.2 接口隔离：别逼着实现类做“无用的承诺”
接口隔离原则说的是：客户端不应该被迫依赖它不使用的接口。大白话就是，接口要小而专，不要大而全。
我见过一个典型的胖接口。公司内部有一个Worker接口，定义了work()、eat()、sleep()、meeting()、writeReport()五个方法。有个人力资源系统想让“实习生”也并入员工体系，于是实习生类实现Worker，但meeting()和writeReport()对实习生根本不适用，只能写成空方法或者抛异常。这种空实现就是坏味道，说明接口设计没有隔离。
按接口隔离原则，应该把接口拆开：Workable管干活，LivingBeing管吃饭睡觉，Reporter管写报告。实习生实现Workable就完了，没必要承担它不关心的接口。调用方也受益：一个团队展示页面，只想调work()，它面对的接口类型就应该是Workable而不是那个巨大的Worker，这样依赖面小，改动受影响的面也小。
接口隔离和单一职责容易搞混。我的区分方法是：单一职责关注的是类内部的聚合度，接口隔离关注的是外部调用方的依赖面。一个类内部很干净，但如果它暴露的接口太宽，调用方被迫感知它不需要的东西，那照样是接口隔离被违反。打个比方，单一职责是“你把自己的房间收拾干净”，接口隔离是“别把房门钥匙配给所有路过的人”。
实操上，接口拆分也不能太碎。两个方法就拆一个接口，那叫碎片化。判断依据还是那句老话：看变化方向。如果两个方法总是同生共死、一起变化，放在一个接口里没问题；如果它们各自有独立的调用方和独立的变更频率，就该拆。
4. 依赖倒置与迪米特法则：决定系统骨架的两条
4.1 依赖倒置：高层不依赖底层，细节不依赖抽象
依赖倒置原则的字面意思容易把人绕晕：高层模块不应该依赖低层模块，两者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。
我习惯用“打电话”的类比来理解。你（高层）想联系一个人（低层），如果你直接握着他的手机号打电话，那每次他换号码你都得重新记。更合理的做法是你有一个通讯录（抽象层），里面存了“联系某人”的映射，你只需要调通讯录就行。换个联系人，改通讯录，你不受影响。
代码里的场景更具体。比如你的业务层需要一个订单存储，如果业务层直接依赖某个数据库封装类：
public class OrderService { private MySqlOrderStore store = new MySqlOrderStore(); public void save(Order order) { store.insert(order); } }看，这个类想升级用Redis做缓存前置，或者想换PostgreSQL，都得改OrderService。而且最难受的是单元测试：你想测OrderService的逻辑，但MySqlOrderStore连的是真实数据库，测试跑一次要等好几秒，数据库一挂测试就红。
按依赖倒置，先定义接口：
public interface OrderStore { void save(Order order); Order findById(String id); }OrderService只依赖OrderStore接口，MySqlOrderStore、RedisOrderStore分别实现它。测试时注入一个内存实现，测试速度飞起，数据库不参与也没关系。这就是依赖倒置带来的两个直接好处：可替换性和可测试性。
这里我要特别强调：依赖倒置不是一个纯代码层面的原则，它更是模块划分的原则。很多时候你代码写得很“依赖倒置”，但模块依赖关系一画出来还是乱，那是因为抽象层放错了地方。正确的做法是，**抽象接口应该跟高层模块放在一起，由高层模块定义“我需要什么”，低层模块来实现“我能提供什么”。**如果把抽象放在低层模块里，高层还是间接依赖了低层，等于换汤不换药。
4.2 迪米特法则：别跟陌生人说话
迪米特法则也叫最少知识原则：一个对象应该对其他对象有最少的了解。翻译成大白话就是，尽量别调用“通过另一个对象才拿到的对象”的方法。
最常见的违规代码长这样：
public void process(Order order) { User user = order.getUser(); String phone = user.getPhone(); smsService.send(phone, "订单已成立"); }这段代码的问题在于，Order本该对自己的数据负责，但调用方越过它直接去跟User聊天，还拿走了User的手机号。如果哪天用户手机号字段改名，或者获取方式变了，你需要改的不止User，还有所有这种“链式调用”的地方，牵一发动全身。
按迪米特法则，应该把行为收回到Order自己身上：
public class Order { private User user; public String getContactPhone() { return user.getPhone(); } }调用方直接order.getContactPhone()，它不知道手机号是从User还是从别的地方拿到的。哪天手机号来源变了，只改Order一个地方。
这里要强调：迪米特法则不是禁止调用，是禁止对不直接拥有的对象发号施令。我自己判断的准则是：这个方法调用的对象，必须是“我自己创建的、我自己持有的、或者作为参数传进来的”。三者之外的对象，都要警惕。当然，这也不是绝对的，像stream()这种链式操作本身就是一种风格，我们不能把原则教条化。迪米特法则的真正价值，是让你意识到“一处修改引发全局崩溃”这类问题，往往就藏在过深的调用链里。
5. 六大原则的权衡与落地顺序
5.1 原则冲突的时候，怎么取舍
学了这么多原则，你可能已经发现它们有时候会打架。单一职责要求类尽量小，拆多了类，类之间的调用关系变复杂，又可能违反迪米特法则；开闭原则要求抽象，抽象多了，系统结构复杂，学习成本上升。这些问题都很现实。
我的取舍经验是：优先保证开闭原则和依赖倒置，因为它们影响的是系统的扩展能力和模块边界，是架构层面的东西，后期改起来成本最高。其次是单一职责和里氏替换，它们影响的是类的内部质量，虽然也重要，但重构成本相对可控。接口隔离和迪米特法则更多是设计习惯，能在写代码时顺手做到最好，做不到也不用过度焦虑。
说个真实例子。某次我负责的一个模块，业务逻辑非常复杂，状态流转有七八种。设计的时候，我为了追求单一职责，把状态判断、行为执行、结果通知全拆开了，结果类数量翻了一倍，调用关系也变得特别绕。后来代码评审的时候，同事一句话点醒了我：这个业务场景的核心变化点是“状态转移”，那我应该重点抽象的是状态机，而不是把所有行为都拆成独立的类。那次之后我学到的教训是：**原则是为变化点服务的，你得先认清当前代码“哪里最容易变”，再决定用哪条原则去重点应对。**不是每个地方都要套满六条。
还有一点想提醒你：别为了满足原则而牺牲可读性。我见过有人为了“依赖倒置”，把一个简单的工具类也包装成接口加实现加工厂，结果找了一圈发现这个接口只有一个实现类。这种情况写清楚点，直接用一个具体类，反而更好。原则是工具，人是目的。代码是写给同事看的，其次才是给机器跑的。
5.2 拿到一个“历史项目”时，该从哪里下手
如果让我接手一个烂摊子，我不会一上来就全面重构，那风险太大，容易被产品经理和测试同时追杀。我一般按这个顺序来：
第一步，先找“最痛的点”。看看线上哪个模块改一次挂一次、改一次要牵动十个文件的，把它标记出来。第二步，分析这个模块违反了哪些原则，把违反点列出来，做成一个“坏味道清单”。第三步，按“先解耦、后收敛”的顺序动手：先用依赖倒置把外部依赖（数据库、消息、第三方接口）跟业务逻辑隔离开，让核心逻辑可以先脱离环境跑起来；再按单一职责拆分类，让每个类变得短小清晰；最后处理继承体系里的里氏替换问题，把不合理的继承改成组合。
这个顺序背后是有逻辑的。外部依赖不隔离，你连单元测试都写不了，改起来心里没底；类的职责不清晰，你就算知道某个行为有问题，也找不到该改哪；继承体系不动，子类之间互相影响的问题会一直存在。隔离是地基，拆分是承重墙，修继承是装修。顺序反了，容易返工。
我还专门整理过一次比较成功的落地经验。那是一个上线的报表系统，核心导出逻辑混杂了权限判断、数据查询、模板渲染、文件上传四个职责。我第一步是把“数据查询”和“模板渲染”分别做成接口，让报表模块只依赖接口。第二步把原来的大方法拆成独立的处理器类，每个类只负责一个阶段。第三步把原本深藏的“导出文件存储”抽象成存储接口，测试时注入内存实现。三步走完，整个模块的改动风险降了一大截。最直观的感受是：以前加一个新的报表格式，要在主流程里改三个地方；现在只需新增一个渲染器，注册进去即可。
6. 常见问题与排查技巧实录
6.1 典型问题的症状与根因速查
我在评审代码和排查线上问题的时候，总结了一套“症状→根因”的对照思路，整理成表格分享给大家。
| 症状 | 大概率违反的原则 | 处理建议 |
|---|---|---|
| 一个类超过500行，方法超过10个，改一个需求要翻遍整个类 | 单一职责 | 按变化方向拆分，先拆外部依赖，再拆内部行为 |
| 新增一种实现，要改原来的判断分支，且分支层层嵌套 | 开闭原则 | 抽象公共接口，用策略或工厂模式替代条件分支 |
| 子类重写父类方法后，基类调用方行为异常，或出现偶发bug | 里氏替换 | 检查子类的前置条件、后置条件、异常约定是否被破坏 |
| 调用方为了一个方法，不得不实现接口里的一堆无关方法（空实现/抛异常） | 接口隔离 | 拆分胖接口，按调用方需求隔离 |
高层代码出现new底层实现类，替换依赖要改业务代码 | 依赖倒置 | 定义抽象接口，通过构造器或工厂注入依赖 |
| 代码里出现a.getB().getC().getD()这样的长链式调用 | 迪米特法则 | 把链路收回到合适的聚合根上，对外暴露行为方法 |
这张表不是标准答案，但排查问题的时候拿来当线索，效率很高。比如看到一个空实现的方法，你不用纠结“是不是设计失误”，直接往接口隔离那边想，大概率能定位。
6.2 我在实战中踩过的三个坑
第一个坑：过度拆分类。有段时间我被“单一职责”洗脑，连一个很简单的值对象都要拆成三个类。结果代码是“整洁”了，但项目里全是跳来跳去都找不到逻辑的碎片类，同事看了一天代码直呼看不懂。后来我意识到，单一职责是针对“变化原因”的，一个对象如果没有独立的变化原因，就不值得为它单独开类。
第二个坑：抽象放错位置。一次重构，我把接口定义在了实现类所在的基础模块里，结果是业务模块虽然只依赖接口，但实际编译时还是把整个基础模块拉进来了，依赖倒置形同虚设。前面我也提到过，**接口要跟着调用方走，不跟着实现类走。**那次踩坑之后，我再设计模块依赖时，会专门画一张模块依赖图检查一遍，确保箭头方向是从高层指向抽象层，而不是反过来。
第三个坑：教条化套用里氏替换。有次我为了让子类“完全符合”父类行为，在重写方法里加了一大堆校验，结果性能下降。后来有同事跟我说：你这里的子类其实并不是严格的“is-a”关系，你用继承本来就是个错误。与其硬套原则去修饰继承，不如直接改成组合。从那以后我的原则多了一条：如果你发现自己需要很努力才能让继承关系看起来合理，那不如换掉继承。
6.3 什么时候可以打破原则
虽然前面讲了这么多原则，但我必须诚实地说：原则不是铁律，可以打破，关键是你得知道自己在打破什么。比如性能敏感的核心路径上，多一层抽象就多一次间接调用，有时候为了性能直接依赖具体实现，是可以接受的。再比如一些一次性脚本、原型验证代码，根本不会长期演进，直接写死也完全没问题。
打破原则的正确姿态，是在代码里留一句注释：这里为了什么原因，故意违反了什么原则。这样后面维护的人不会困惑，也不会误以为这是规范写法而到处模仿。我在代码评审时，看到这种“有意识的设计取舍注释”，通常都会放行；看到那种“不知道自己在违反原则”的代码，才会打回去要求改。
最后说句实在话。你去看那些写得赏心悦目的开源项目，很少是刻意“套”原则套出来的。原作者往往是把业务想透了，变化点清楚了，自然长成了那样。六大原则不是装饰品，是帮你理清“哪里会变、哪里不该变”的思维工具。多写、多重构、多复盘，这些东西才会从脑子里的概念变成手上的习惯。等你哪一天写代码不用刻意想“这条符合不符合开闭原则”了，那才是真的会了。
