你懂SOLID原则吗？

虽然 SOLID 原则不能时刻有效指导编码落地，理解这些原则背后的设计理念，让你迈出了第一步，接下来，你需要做的是在前进的路上，不断地进行编码实践、思考总结，将其内化。

做了这么多年的面向对象编程还是写出违背 SOLID 原则的代码，一看都懂、一做就被怼，敏感度不够，如何是好？

• 难道SOLID原则本身就有错？
• 难道我不应该涉水OOD？
• ……

请先屏住呼吸，我们来看看 SOLID 叫什么：

• Single Responsibility Principle，单一职责原则
• Open Close Principle，开闭原则
• Liskov Substitution Principle，里氏替换原则
• Interface Segregation Principle，接口隔离原则
• Dependency Inversion Principle，依赖倒置原则

原则通常较为抽象，别说刚接触 OO 的程序员，有一定经验的人也不一定吃得透。要想提高对 OO 原则的敏感度，第一步，我们要清楚 SOLID 到底在讲什么？本文，袁 Sir 的 SOLID 创业故事将为你揭开一层面纱。

设计小而精美的工具箱，提高顾客体验

袁 Sir 创业初期经营了一家五金器具共享租用店，遇到两类顾客，A 顾客需要剪刀、锤子、扳手、电锯，B 顾客需要锤子、扳手、水果刀、梅花刀。袁 Sir 为了图省事，把这个六把工具同时装在一个工具箱里，每次都把装有 6 把工具的工具箱给 A 或 B 租用。

经过几次借还，袁 Sir 收到顾客的抱怨，为什么呢？因为袁 Sir 这么做增加了 A 和 B 的负担，首先多了两把工具，扛来抗去的累得多。其次，他们拿回去之后会发现：”咦，这两个是啥，我没要这个呀？莫非是增值服务？但我要用来做啥呢？” 结果 A 从未用过水果刀和梅花刀，但 A 还要保管好这两工具，增加了保管的成本。同理，B 顾客也会面临同样的问题。为了提高顾客的体验，袁 Sir 把这两类顾客的工具单独用两个更小的工具箱装好，分别提供给 A 和 B，并得到了两类顾客的一致好评。

袁 Sir 从一开始图一时的方便，塞给顾客他本不需要的东西，经过反思后，从顾客需求出发，只提供顾客想要的东西。投其所好，是他创业悟出的第一个处世之道。

在软件设计中，ISP 提倡不要将一个大而全的接口扔给使用者，而是将每个使用者关注的接口进行隔离。

让客户坚信徒弟能代替师傅干活

袁 Sir 勤勤恳恳经营的五金租用店 2 年，挣了一大把辛苦钱，正好赶上房地产兴起的年头，家装市场跟着兴起，他果断买下一家知名的家具厂，并跟一家私人工匠所展开了合作。

SJ 是工匠所的一名木匠学徒，从师 3 年有余，书架、衣柜、餐桌，门、窗这些家具已经能够到跟他的师傅如出一辙了。

袁 Sir 每次合作都是直接跟 SJ 的师傅对接，而在实际执行过程中，师傅有时候因体力跟不上，就交给 SJ 去做，好在每次生产出来的家具都能够让袁 Sir 满意。几次合作下来，袁 Sir 便相信：徒弟继承了师傅的手艺，师傅能做的这些家具，徒弟也一定能做得一模一样。

2017 年，房地产彻底疯了，袁 Sir 一次性采购订单多出了以往 2 倍。为了如期交付，SJ 的师弟小 Y 也参与进来。不幸的是，个性十足的小 Y 打造衣柜和门窗的方式跟师傅的风格差别很大，设计出来的家具让袁 Sir 一脸懵逼，始料不及的三丈大火烧尽后，袁 Sir 果断地中断了跟这家工匠会所的合作…

[LSP 解读] 小 Y 将其师傅的手艺继承后，但自己又擅自修改了设计风格，结果打造的家具跟袁 Sir 的期望不一致，这就好比子类替换了父类，产生了不一致的行为，软件不能正常运行，这种继承设计存在潜在的问题。

在软件设计中，LSP 重点强调：对使用者来说，能够使用父类的地方，一定可以使用其子类，并且预期结果是一致的。

简而言之，子类不应该去修改父类已有的功能（在 Java 中，体现为子类重写了父类中非抽象的方法）。如果你的继承体系中出现了这种替换后不一致的现象，需要警惕你的继承是否合理了。

关于代码示例，请在文末参考阅读文章《让里氏替换原则为你效力》。

清晰良好的合作协议，让彼此更加信任

经过上一次不愉快的合作，袁 Sir 虽然少挣了一笔钱，还生了一肚子气。但台风来，猪想飞你也挡不住。在房地产彻底疯了的这几年里，袁 Sir 又捞了好几大桶金。有了钱能做什么呢？当然把公司做大，再挣更多的钱呀。

袁 Sir 秉着 ‘麻雀虽小，五脏不能不全’ 的原则，成立了财务部、法务部、行政部、人事部、市场部、销售部，由于期初业务量没有大到招架不住，各部门都是光杆司令，而且人事、行政、财务、法务四个部门由小蔡独管（袁 Sir 流露出了资本家的面貌）。

袁 Sir 要核对一个报销单，就直接找财务部的小蔡办了，要举办一场年会还得找小蔡，想了解上个月的销售业绩，他去找了销售部的老肖，当然找的最多的还是市场部老史。

经过大半年的快速发展，各部门从光杆司令变成了群狼作战。袁 Sir 仍然按照之前的方式办事，但遇到了烦恼 – 前天报销单还是小蔡在处理，昨天变成了小吴，今天又换成了小任。当然，其他部门也产生了相同的现象。苦思冥想，袁 Sir 出了一招：部门的负责人制定一个固定的服务列表，比如财务部小蔡提供服务列表：

1. 核对报销单
2. 处理报销
3. 发工资
4. 招聘新同事
5. 评审绩效
6. 举办年会
7. 审核营业执照

袁 Sir 此时要处理报销、发工资，只用找小蔡沟通就好，至于具体谁去执行，袁 Sir 压根不需要知道。当然其他部门跟财务部合作也轻松了很多。此后袁 Sir 对所有部门都进行了整改。

此时袁 Sir 终于才体会到当老板的一丁点美好了。下班合上电脑前，他敲下了一句话：部门之间得通过约定好的协议来合作，而不用关心对方内部由谁做协议所规定的事项。

[DIP 解读] 一开始，袁 Sir 直接找部门中某个具体执行的人去沟通工作，此时袁 Sir 依赖的是具体实现细节，每次执行的人发生变化会增加袁 Sir 的沟通成本。他让小蔡提供了一个服务清单，小蔡充当了一个抽象/接口，此后他只用找小蔡沟通即可，袁 Sir 从依赖具体实现细节转变到依赖抽象。

在软件设计中，DIP 提倡使用者依赖一个抽象的服务接口，而不是去依赖一个具体的服务执行者，从依赖具体实现转向到依赖抽象接口，倒置过来。

各司其职，工作效率会大大提升

袁 Sir 起初让小蔡统管了人事、行政、财务、法务四个部门，业务扩张后也只是给小蔡多招了 10 来个人。小蔡大脑里就不得不绷紧四根弦，他要给部门各个同事合理分配任务，确保公司能够正常开展日常活动、人员考核培养、工资发放等工作，当然还有一些诸如工商督查、账务审核、信息安全审核等敏感的活动。

暂且不说小蔡有多累，关键是有一次捅了个篓子，差点没葬送公司前程。

一天，工商局来了几个人审核公司的营业资质，就在小蔡跟工商局负责人交涉的过程中，其他管理账目的两位同事因为一项没法对齐的数据起了点小争执，全然忘记还有工商局调查人员在，口角中抖了一些账目相关的敏感信息，好在小蔡反应快，及时进行了制止，当然也做了一些额外的安抚工作，把这事给糊弄过去。

这事传到袁 Sir 耳中，加上小蔡多次跟袁 Sir 反馈业务太杂，不但累且容易出篓子，袁 Sir 这才把几个部门进行了拆分，人事部交给了小任，行政部交给了小邢，法务由老发掌管。

经过几个月的验证，让袁 Sir 欣喜的是，运营成本不但没有增加，员工的工作状态也比之前大有改善。

从此，财务部门小蔡提供的服务列表：

1. 核对报销单
2. 处理报销
3. 发工资

人事部门小任提供的服务列表：

1. 招聘新员工
2. 员工绩效考核
3. 员工培养

行政部小邢提供的服务列表是：

1. 举办年会
2. 接待来宾

法务部提供的服务列表是：

1. 审核营业执照
2. 审核信息安全

周五晚上 10 点，袁 Sir 走出办公室大门，哼着小曲自言自语道：还得专门的人干专门的事呀，勿贪多，贪多必失…

袁 Sir 睡前打开电脑，在备忘录写下：分离关注点（专注）是做好一件事的有效途径，如果同时需要兼顾多项不太相关的工作，注意力就必须在不同的上下文切换，会大大降低工作效率，更糟糕的是可能会出现一些意外的灾难。敲完欣慰睡去。

在软件设计中，SRP 提倡让一个类只处理一组相关的事情，控制了它的变化方向，后期也能更好的定位。如果引发变化的因素很多，会导致类的职责过多，难以维护，常见的上帝类就是这么形。

引入中间人读书大使，解放自己

经过几年的发展，袁 Sir 的公司俨然已经步入正轨，他开始思考公司文化建设方面的事情。

袁 Sir 一直对读书非常重视，他想在公司把读书运动搞起来，每周搞一次分享大会。起初他提议由行政部和人事部来牵头搞，两个部门轮流来，自己直接分别跟两个部门负责此事的负责人对接。

两个月过去了，公司的读书氛围得到大大提升，书架遍布公司各个角落，水果时间也从八卦转向了读书心得的分享。

欣慰之余，袁 Sir 也感觉有点力不从心。经常出现这种现象：有时候去他找人事部的小史商量工作，却被告知这周轮到行政部的小郑了，而去找小郑的时候，被告知市场部也是组织者之一，本周轮到市场部了。

袁 Sir 因为业务繁忙，加上翻来覆去的对接工作，搞得心累，但他又很重视这件事情。琢磨良久，他决定给自己招一个读书会大使（有钱了可以稍微任性一下下），每周要开展读书运动大会前，他直接跟读书大使对接，大使后续再去协调对应的部门开展工作。

经过这么一整改，袁 Sir 得到了解放，再也不用关心这周该由哪个部门组织，下次会有什么新的部门加入进来。

看着读书运动在公司里遍地开花，袁 Sir 心想着年底了要给读书最多，分享最多的同事多发 12 个月的年终奖…

[OCP 解读] 在一开始，袁 Sir 支持某个部门举办的读书会，后续只要有新的部门要负责举办时（好比功能上的扩展），袁 Sir 都要改变自己的沟通方式，这意味着他自身做出修改才能支持新的需求，此时，袁 Sir 对修改是开放的。引入读书大使后，相当于做了一个抽象，袁 Sir 只需要依赖这个抽象，再有新的部门举办读书会时，他就不需要在改变沟通方式了，此时，袁 Sir 对修改是关闭的，对扩展是开放的。

在软件设计中，OCP 提倡对修改关闭，对扩展开放。建议为你的服务调用者提供一个他需要的抽象、高层次的行为接口，后期你的服务有新的种类，你只需要新增一个实现该抽象、高层次接口具体服务，而不需要修改调用者的使用方式。

创业故事回顾

从袁 Sir 的故事中可以看出来，袁 Sir 在不同阶段之所以面临各种不同的痛点，主要原因有两点：

1. 关注的事情太多
2. 关注事情的细节

创业初期，袁 Sir 这么做问题不大，公司在不断地发展壮大（如同软件的演变），袁 Sir 就需要琢磨出新的方案，而这些方案的核心观念无非两个：

1. 分离关注点
2. 引入中间人

在面向对象软件设计中，关注点分离，其实体现的就是软件设计的精髓 – 高内聚，低耦合，引入一个中间人 则跟 面向抽象编程 有异曲同工之处。

写在最后

SOLID 原则，它其实是在帮助指导我们设计出高内聚，低耦合 的软件，降低软件后期的维护成本。虽然原则不能时刻有效指导编码落地，理解这些原则背后的设计理念，让你迈出了第一步，接下来，你需要做的是在前进的路上，不断地进行编码实践、思考总结，将其内化。

最后，我想跟技术人员共享一个关键词汇 – 用户视角/业务视角：

我们学到了的很多技巧（设计原则、设计模式、重构手法等），如果忘记初衷，失去目标，代码写得再炫酷、再健壮，也很难体现出应有的价值。从业务需求出发，以用户视角看问题，致力编写出简洁可用的代码即可。

文章转载自：ThoughtWorks 洞见（ID：TW-Insights）

原文链接：你懂SOLID原则吗？