程序员旭阳的专栏

最近review公司的代码，发现代码耦合程度特别高，修改一处，不知不觉就把其他地方影响到了，这就让我思考该如何让我们写的代码足够内聚，减少耦合呢？"高内聚、松耦合"是一个非常重要的设计思想，能够有效地提高代码的可读性和可维护性，缩小功能改动导致的代码改动范围。它可以用来指导不同粒度代码的设计与开发，比如系统、模块、类，甚至是函数，也可以应用到不同的开发场景中，比如微服务、框架、组件、类库等。本文我们来探讨下如何让我们的应用做到高内聚。

最近review公司的代码，发现现在整个代码层级十分混乱，一个service类的长度甚至达到了5000多行。而且各种分层模型DTO、VO乱用， 最终出现逻辑不清晰、各模块相互依赖、代码扩展性差、改动一处就牵一发而动全身等问题。我们在吸取了阿里巴巴的分层规范以及网上的一些经验后，重新梳理总结了属于我们项目的分层规范。

软件设计SOLID原则中有一个最基础的原则就是单一职责原则，我想绝大部分的程序员都知道，而且都理解它的意思，甚至觉得很简单。但是往往“看懂”和“会用”是两回事，而“用好”更是难上加难。好比我们项目，一开始一直和大家强调类的单一职责，随着业务不断发展，不同的同事都往这个类“添砖加瓦”，最终导致一个类5000多行，如下图所示，连IDE都受不了，变得卡顿，可想后面维护成本有多大了，究竟为什么会这样呢？又该如何解决呢？

最近在看公司项目的代码，看到了大量的继承体系，而且还是继承了多层，维护、阅读都十分的困难。在查阅了一些资料以后，包括《Effective Java》一书中的第16条提到“组合优先于继承”。那继承到底会暴露什么问题呢？为什么更推荐优先使用组合呢？欢迎关注微信公众号「JAVA旭阳」交流和学习不知道大家项目中继承用的多吗？其实在JDK中就有许多违反这条原则的地方，比如栈Stack类并不是Vector，不应该有继承关系，但是实际上就是继承自Vector。

软件设计原则中有一条很关键的原则是开闭原则，就是所谓的对扩展开放，对修改关闭。个人觉得这条原则是非常重要的，直接关系到你的设计是否具备良好的扩展性，但也是相对比较难以理解和掌握的，究竟怎样的代码改动才被定义为“扩展”？怎样的代码改动才被定义为“修改”？怎么才算满足或违反“开闭原则”？别急，本文将展开详细阐述。欢迎关注微信公众号「JAVA旭阳」交流和学习本文讲解了软件设计中个人认为最重要的一个设计原则，开闭原则，即对扩展开放，对修改关闭，这会指导我们写出扩展性良好的代码，设计出扩展性更好的架构。