关于模块化设计的内聚和耦合的个人理解

在接触框架和设计模式的时候，有两个词经常被文章提及，那就是内聚和耦合。

在一篇博客里我看到博主讲，在一些小的项目开发过程中，可以不必太在意程序的设计，因为小的项目，是以在短期内交付为目的的开发过程。但是如果是一个程序产品的开发，那就一定要在设计模式和模块化开发上下功夫，因为一个优秀的产品，一定是易于维护的，可以修改的。所谓的框架，其实也是一个模块化开发的过程，模块化的开发，也就是方便以后对自己的代码进行修改和维护。以上可能都是废话，自己没有切实的项目开发经验，所有的所有都是从别人的话里学来的。

什么是内聚？

内聚是衡量模块内成分关联的“单位”。通俗的讲，就是A做A的事，A只做A的事。

偶然内聚：一个模块内的各部分没有任何联系，就叫偶然内聚。例如一个程序，我就用一个类来写可不可以？可以，什么变量，函数都塞这个类里，今天写完明天来找保证你自己都头大，更别说项目交付给别人来管理了。

逻辑内聚：一个模块内的各部分存在逻辑上的联系，通过参数不同来实现不同功能。这种做法也比较蠢，我能想到的例子就是，我捡到一块鼠标垫，那我要买个鼠标，买了鼠标要换台电脑，换了电脑再买个大点的房子，房子都大了是不是得找个漂亮的女朋友。。。不敢往下想了，虽然他们逻辑上是联系在一起的。

时间内聚：需要在某个时间段内执行的方法放到一起，例如在场景加载时需要处理的一些数据。

过程内聚：在一个过程中，你需要按一定的顺序来执行你的代码块。。。ABCDEFG这样下去的，把他们写到一起，看起来很有顺序感。

通信内聚：指模块内所有处理元素都在同一个数据结构上操作或所有处理功能都通过公用数据而发生关联（有时称之为信息内聚）。即指模块内各个组成部分都使用相同的数据数据或产生相同的数据结构（来自百度）。自己翻译一遍就是，一团面（数据），你要用来包饺子下面条还是当橡皮泥玩，只要是处理这团面的，那就全写一起。

顺序内聚：和过程内聚有点相似，和一个功能密切相关，A输出的参数为B传入的参数，B输出的参数为C传入的参数，那把他们都写一起。

功能内聚：一个模块内的所有元素，都是为了处理一个功能的，这是最强的内聚。例如，在3D场景中，我们需要播放声音，那就把所有有关声音的东西写在一起，你需要播放什么声音的时候告诉我一声，我来播放就好。

我个人觉得，并没有什么差的内聚，根据自己的需要来设计内聚的程度，方便开发和管理就好。

功能内聚模块的一个重要特点是：他是一个“暗盒”，对于该模块的调用者来说，只需要知道这个模块能做什么，而不需要知道这个模块是如何做的。（来自百度，自己并没有很好的理解这句话）

什么是耦合？

耦合是衡量模块和模块之间依赖程度的“单位”。也就是A做事的时候，是不是需要B的帮忙。

内容耦合：B模块直接访问A模块的内部数据，或者不经过正当的入口进入。例如B模块是用来计算武器伤害的，但是通过A模块能访问甚至修改B中的数据，那不是可以通过B来实现一刀九十九亿伤害，一刀满级的酷炫页游效果？

公共耦合：很多模块访问同一个全局数据结构，咳咳，想想都可怕，公交车诶，孩子姓王还是姓张？

外部耦合：很多模块访问同一全局简单变量，而且不通过参数传递该全局变量的信息。公交车就公交车了，我们上车刷卡别给人家带来什么负面影响。

控制耦合：模块之间不传递数据，而是去传递一个控制信息。最简单的理解，就是传递一个true or false。

标记耦合：模块之间不传递数据，而是传递数据结构，也就是数据的地址。这样地址一旦改变，相关联的模块也就随之改变了。

数据耦合：就是传递数值。。。

非直接耦合：两个模块之间没有什么直接联系，他们的联系是通过一个第三方或者主模块来实现。耦合度最低，模块的独立性最强。

为什么需要“高内聚，低耦合”？

实际上，实现“高内聚，低耦合”在一定程度上会使代码量增大，也意味着需要为这个项目设计一个合理的模式，这样会加大项目的支出。但是这是为了方便项目或者产品日后的开发和维护，是一个长远的考虑。

如文章开头说的一样，如果是一个小的项目，一味去追求高内聚低耦合只会得不偿失。

以上，一个小菜鸟对模块化开发中的内聚耦合的理解，也许有不对的地方，轻喷~毕竟我还是祖国的花朵