问题：

有没有人质疑过这个设计思想？

包括前后端分离，本质上不都是一种「分门别类、统筹规划」的管理思想嘛。

最近在看《翻转式学习》，作者在里面吐槽了说真正的教育根本就不应该分学科和科目。（我感觉这个想法太高深了，没敢往下想）

而且最近受All in one影响蛮大的，忽然就想到了在软件开发中的「低耦合、高内聚」的设计思想。

凡事有利必有弊嘛，还请大家可以理性讨论一下啦！

回答：

作者：韦易笑
链接：https://www.zhihu.com/question/347264877/answer/834666851

举个例子就明白了

低内聚，高耦合：

高内聚，低耦合：

你觉得谁更好维护？更容易调整？出错了更容易排查？

所以写程序需要起码的审美，漂亮和丑陋都分不清的话，怎么设计复杂系统呢？

—

PS：关于你提到的 all in one 的观点和 “高内聚，低耦合”是不是矛盾的问题？

一点不矛盾，all in one 说的就是 “高内聚”的思想，只是它没说完另外一面“低耦合”

再举个例子，原本 PC 插在主板不同位置的各个设备，到了手机时代用 all in one 的方式做成了 soc，降低了成本，提升了性能，但是仔细看它内部：

手机 SoC 内部各个模块之间的协同，何尝不是高内聚低耦合的设计？再把镜头拉远点，站在整块主板的角度，把 SoC 看作一个高内聚的整体的话，这块 all in one 的 SoC 正是通过精密的设计和良好的封装从而对外层（主板上其他设备）提供了低耦合的接口，降低了手机厂商的生产技术门槛：

这就是 “高内聚”和 “低耦合”互相转化的关系，所以这其实是一枚硬币的两面，并且可以一直循环递归下去，视角不同罢了。

对比低内聚高耦合的情况，很多人更容易犯低内聚低耦合的错误，写个 1+1=2 都要先建立个文件弄个 interface ，再建一个文件做实现的类，里面放个runable 的匿名类，外面再套一个静态方法 GetInstance，封装是多了，但空洞无物，内部实现繁琐，外部调用啰嗦（虽然也是低耦合），所以还得加一句，保持简单性和可拆分性。