软件里面的耦合性是指各个模块配合起来完成一个可交付的功能时，这些模块相互之间的依赖程度，或者说需要它们互相配合的这种需要的强烈程度。我可以举个简单的例子，因为我最近也常用这个例子。
比如你的客户或领导要你做个软件，为他提供一个苹果和一个梨子。那你可能很自然就会觉得要把这个软件划分为两个模块，一个提供一个苹果，另一个提供一个梨子。
如果你这么做，这两个模块可以说就是低耦合甚至无耦合的。
因为你这种做法实际上是把可交付成果进一步分解为两个小的可交付成果。
所以这两个模块在“配合起来完成一个最小的可交付成果”这件事情上，对它们互相的配合的需要就是没有，虽然它们仍然要配合起来完成最终的可交付成果，但是毫无疑问的是，对这种配合的需求没有随着模块的划分的深入而增加。
但是你也可能采用另外的划分方式。
比如你还是决定划分为两个模块，一个用来提供上半个苹果和上半个梨子，一个用来提供下半个苹果和下半个梨子。
这种划分方式可能是违反直觉的。但是他确实是一种可以存在的划分方式，而且可以有它的理由。
比如你发现苹果和梨子的上半部分都是黄的，下半部分都是绿的，那么你这种方式就可能便于你为它们统一着色。
每个模块进行着色时不用换画笔的颜色了。
但是采用这种划分方式，由于你的客户并不可能接受什么半个苹果和梨子的交付物，所以你的两个模块必须配合起来，要同时完成工作才能提供一个交付物。
而且它们还要常常顾及对方的感受，比如第一个模块它提供的上半个苹果的直径就要跟第二个模块提供的下半个苹果的直径一致才行。
梨子那边也是一样。所以它们必须在更多方面配合好才能完成一个可交付成果。也就是耦合度更高。那你可以知道后面这种方法会有几个问题，首先是违反直觉，不易理解，其次修改一个模块就要同时修改另一个模块。
这些都导致在客户变更需求的时候，或者你自己需要修改它的时候，更容易陷入混乱。所以才会提倡低耦合。
