刚入行的时候我就知道“高内聚、低耦合”这六个字面试时背得滚瓜烂熟。但说实话真正理解它是什么、为什么要这样做是在写了三年代码之后。不懂的时候以为只是抽象的概念前两年写代码我对这六个字的理解停留在字面意思上高内聚就是把相关的东西放一起低耦合就是少依赖别人。听起来很简单对吧那时候写代码的思路很简单产品提了需求我就在现有的Service里加方法或者在Controller里直接处理新逻辑。Spring Boot的自动装配太方便了Autowired一加哪里需要点哪里。一个Service类从最初的几百行慢慢膨胀到上千行订单逻辑、用户逻辑、库存逻辑、物流逻辑全搅在一起。当时觉得这样没问题啊代码能跑功能正常单元测试覆盖率也还可以。直到有一次产品需求变更要调整订单状态的流转逻辑。我花了整整三天改代码改完这一块发现另一块逻辑不工作了。修好了那一块又发现报表数据不对了。牵一发而动全身改得我头皮发麻。那一刻我才意识到我的代码出了问题。可是问题在哪我翻出设计模式的书重新看到那六个字——高内聚、低耦合。之前是背下来的这次好像有点感觉了但又说不太清楚。一个重构让我真正懂了真正让我开窍的是一次重构。当时要把一个复杂的订单处理模块拆开我尝试按职责把原来的大Service拆成几个独立的类OrderValidator——负责订单校验OrderPriceCalculator——负责价格计算OrderStatusManager——负责状态流转OrderRepository——负责数据持久化拆完之后发现每个类做的事情变得特别清晰。改价格计算逻辑的时候我只需要看OrderPriceCalculator这一个类不用担心影响到状态流转。因为OrderStatusManager只依赖OrderRepository和几个外部接口的抽象不依赖具体的价格计算实现。这就是“高内聚”——一个类只做一类事相关的数据和方法都封装在内部对外只暴露必要的方法。产品改需求了我能快速定位到要改哪个模块而且改动范围可控不怕改出连锁反应。也正因为模块之间依赖的是接口而不是具体实现改价格算法时只需要换一个实现类注入进去就行完全不用动OrderStatusManager的代码——这就是“低耦合”。那一刻我明白了一件事我以前是在一个巨大的Service里用“注释分区”假装模块化但编译器根本不知道这些分区改动时所有代码都在同一个文件里彼此之间没有任何隔离。而真正的模块化是用类和接口的边界做隔离。理解后的三个判断标准现在我看一个项目的代码质量会用三个标准判断它是否符合高内聚低耦合的原则第一改动一个功能时需要改几个文件如果需求变更是家常便饭每次改动都涉及七八个甚至十几个文件那耦合度一定高了。好的设计应该让90%的需求变更只影响一到两个模块。第二这个类我能用一句话说清楚它是干什么的吗如果你只能用“它负责订单相关的所有事”来描述一个类那它的内聚度一定不够。高内聚的类应该能用一句话精准描述它的单一职责。第三新同事上手改代码敢不敢只改一个文件就提交如果新同事每次改完都要问“我改了这里会不会影响那里”说明模块之间的边界不够清晰耦合太紧。这六个字到底在说什么说到底“高内聚、低耦合”这套原则追求的不是代码本身的某种美学而是——当变化发生时你需要付出的代价有多小。商业世界里的需求永远在变一个好的软件设计不是把未来所有变化都预测到而是让未来发生的变化尽可能被限制在局部不会引起全局的连锁反应。高内聚保证了这个“局部”足够小且足够完整低耦合保证了这些“局部”之间不会互相传染。现在回过头看那六个字从来不是背出来就完事的。它需要在一次次重构中、在一次次被需求变更折磨之后才能真正刻进代码里。如果你现在还觉得它只是一句口号可能只是因为——还没遇到那个让你头皮发麻的需求变更。