谈谈低耦合高内聚的设计思想

前言

我们在做产品设计的时候，有时候会发现两个业务模块“你中有我、我中有你”，界限不清晰。结果就是，改动其中任意一个模块都会导致另一个业务模块也需要更改或者上线出问题。这种情况在技术上就叫做“高耦合”。这种设计会导致整个系统非常混乱，维护成本极其高，应当极力避免。实际上，好的设计应该是“低耦合、高内聚”。

什么是“低耦合、高内聚”

我们来看一个例子，在电商平台中会有商品模块、订单模块。订单商品明细依赖于商品、商品销量又依赖于订单商品明细。这样就形成了相互依赖，也就是“高耦合”。这个时候如果更改商品信息，就会导致订单商品明细的信息也更改（这会导致用户看到的订单明细和之前购买的不一致）。如果调整了订单明细信息，那么商品的销量也会随之变化（这会导致商品销量数据不准确）。实际业务肯定不能这么设计。怎么改进呢？具体操作如下：

• 订单商品明细的商品信息应该是静态的，不随着商品变更而变更，因此应该在下单时就将当时的商品快照信息存下来。这样订单商品明细就不再依赖于商品模块了。

• 商品销量应该由单独的数据统计模块从订单商品明细中提取，这样商品销量就不再直接依赖订单模块了。

再举两个大家熟悉的生活中的例子。

第一个例子是我们租房子，如果租客自己找房东直租，房东自己直接找租客。这就意味着租客需要和很多房东对接，房东也需要和很多租客对接。这样的效率肯定很低，因此中介诞生了。租客只需要对接中介，房东也只需要对接中介，从而简化了房东和租客的关系。将直接关联的两个业务对象的关系变成间接关联或者不关联，这就是“低耦合”。

第二个例子是二手房交易，我们知道二手房的交易非常复杂，涉及很多环节，比如核验房源真实性、查看购房资格、签署合同、首付款、解押、网签、贷款、过户办证等等。如果是房屋买卖双方去跑通所有的环节非常耗费心力。这个时候，房产中介公司将所有这些业务集中起来，由懂这块的业务人员来办理。这样，对于房屋买卖双方而言，就只需要交给中介办理就好了。对于二者而言，房产中介公司将房屋交易相关的业务全部包揽了下来，就实现了“高内聚”。将高度关联的业务功能集中在一个模块内，从而让其他业务对象使用这些功能更加简单，这就是“高内聚”。

产品设计中怎么应用？

“低耦合、高内聚”在技术开发上提倡比较多，按照这种思想设计的软件扩展性、可维护性会更好，通常在软件架构设计上采用得比较多。那么，对于产品设计来说，又该怎么应用呢？具体来说会有下面几种应用：

• 产品架构设计：架构设计不仅仅是程序员的事情，实际上如果产品架构设计不合理，那么从源头来说就有问题了，程序员设计的架构再优雅可能也无法解决产品架构的缺陷。在产品架构设计时，我们就应该梳理出来各个业务模块和业务模块之间的关系，然后用“低耦合、高内聚”的原则来检查业务模块的划分是否合理。如果存在“高耦合、低内聚”的情况，那么应该引入新的模块来降低耦合，将零散且相高度关联的模块合并为一个业务模块。这样就能够保证产品架构的合理性。

• 业务对象关系梳理：具体到单个模块时，我们就需要分析模块内的业务对象的关联关系。这种情况下，同样可以借鉴“低耦合、高内聚”的设计思想，避免业务对象之间相互依赖，同时也可以通过合并业务对象来减少不必要的业务对象。

举两个典型的产品设计例子。第一个例子就是 RBAC 权限管理，通过引入了角色这个模块，避免了账号模块和权限模块的“高耦合”。第二个例子就是我们之前在《物联网设备接入产品该怎么设计？》一篇中提到的，在运营平台可以将物联网设备的档案管理、数据对接配置、设备分配等繁琐的功能由平台配置，实现“高内聚”，从而简化租户侧的使用，达到“开箱即用”的效果。

总结

由于我是技术出身的产品人，曾经有不少产品经理问我如果要了解技术知识，该具体学习哪些？我当时建议是有两门知识学了对产品设计帮助挺大的，一个是我们这篇讲到的这种设计思想，有一本书叫做《设计模式》，专门讲解设计高质量软件的思想；另一个则是数据库，可以帮我们理解业务对象是如何对应数据层的，这块我自己专门写了一个面向产品经理的数据库小课，共30篇（实际31篇）超过4万字，目前已完结，有兴趣的可以扫描下方二维码订阅。