高内聚低耦合是一个优秀系统的基本要求。内聚描述的是模块内部各个元素彼此结合的紧密程度，越紧密，内聚性越高，单一责任原则越强，单一责任指一个模块负责一项任务。

　　耦合描述的是模块外部各个模块彼此结合的紧密程度，越紧密，耦合性越强，模块的独立性越差。

　　怎么做到产品的高内聚和低耦合?

　　内聚和耦合不仅适用于软件工程，也适用于产品设计及其他方面。此处讨论的产品以互联网产品为主，暂时不讨论其他的产品。内聚强调的是内部的联系，耦合强调的是外部的联系。

　　高内聚

　　在互联网产品(例如一款app)中的高内聚是指，在系统、模块、功能、实体等层面保证每个系统、每个模块、每个功能、每个实体在用户认知中的统一且单一，并符合整体特征、逻辑和自然。

　　以唯品会举个例子，唯品会平台化后，在平台层面，各个平台都有其独特性，具有极高的内聚性。在模块层面，单从交易平台来看，商品展示、购物车等模块也有其独特性，商品展示模块包括商品卡片、商品详情等页面只做展示用途，购物车模块会进行拆单合单、优惠计算等是下单前的预处理。在功能层面，单从商品卡片来看，封面、小图、价格、标题等各司其职，但是有“满1件打7折”和“3.6折”两个折扣，此处折扣聚合度不够，就会让用户不明白到底打几折。

　　唯品会平台化业务架构蓝图

　　PC端商品卡片

　　低耦合

　　在互联网产品(例如一款app)中的低耦合是指，在系统、模块、功能、实体等层面保证每个系统、每个模块、每个功能、每个实体之间的联系是简单而不是复杂的。

　　以微信公众号群发为例，当前方案为方案A，方案A的群发对象的维度只有三种，标签、性别和地区(中国可精确到市)，维度内不可多选，维度间为与关系。方案B则是用了个【群发对象】弹窗，把所有用户列出来进行多选，维度则作为筛选条件。方案A的耦合度就比方案B要低，因为方案A只是与【维度】有联系，和【用户】无联系，不展示用户也不计算用户数量;方案B与【用户】【维度】均有联系，要通过【维度】去筛选【用户】，还要把用户数量算出来。(PS：其实要不要直接选用户也是一种需求，需求调研时也需要注意。微信和微信公众号是两款世界顶尖的C端和B端产品，非常值得研究，它们所蕴含的东西可不只是我们直观看到的那些。)

　　方案A

　　方案B

　　高内聚和低耦合，具体多高多低是需要基于业务需求(特别是需求调研中的边界确定)考虑的，要追求合适较高的内聚和合适较低的耦合，而不是“全内聚“和”无耦合“。”全内聚“是指内部关系极其单一，模块粒度细到极致，什么都是模块，这种情况会导致耦合度极高，因为什么都得调用，一般都是部分调用部分关联的。”无耦合“是指外部关系极其简单，几乎没有模块，就是一个整体，这种情况会导致内聚极低，什么都是=什么都不是。

　　整体上看，随着业务的发展，产品会基于初期的产品架构，在上面搭建很多模块，模块越多导致内聚逐渐降低，耦合逐渐增高，达到某种程度就不得不进行系统重构。达到必须要重构的时间，不仅取决于业务发展，更取决于初期产品架构的健壮程度和产品迭代时是否遵循宗旨有关。

　　为什么人看到猫就知道它是只猫?因为人对猫建立了认知。人是怎么对猫建立了认知?因为人知道了哪些是猫的特征。人是怎么知道猫的特征的?因为人小时候妈妈教他认了几只猫。

　　这整个流程 看到猫→知道这是猫→总结猫的特征→对猫建立认知，就是人的学习和认知路径。

　　其实这不仅是人的学习和认知路径，也是人工智能的学习路径，感兴趣的同学可以自行了解下，我们也可以交流交流。