耦合是什么？就是两个“元素”之间的关联、制约、调用关系。 有几个关键点。1、不能是一个，至少也得是两个。2、要谈耦合，必须说二者有关系的部分，不能去说二者无关的部分。3、不要谈耦合色变。在大多数情况下，耦合是不可避免的，只能尽量减少相互的影响。4、如果是一个，我们可以谈谈是否违反了“单一职责”，但是我们不要谈论“耦合”。当我们把这“一个”分成了“多个”之后，在来谈耦合。
耦合，当一个“元素”发生了变化，其他的“元素”如何调整才能够适应这个元素的变化。 这里的“元素”指的又是什么呢？这个就多了，可以是类（class），可以是函数，可以是人，可以是事物，也可以是零件。 高耦合又是什么？高是一个形容词，形容关联关系非常密切，一个变化后其他的受到的影响非常的大。 低耦合就是影响的程度非常小。
========================= 举例子的时间到了。 我们对电脑硬件都很熟悉吧，那么我们就以pc机的主板、内存、cpu为例来说一下。 我有一台老电脑，里面用的是DDR1的内存，内存坏掉了，到市场上一打听，发现内存都已经是DDR3了。我想买DDR3，但是老主板不支持，想要用DDR3的内存，就必须换主板。可是换主板的话，原来的cpu也用不了了。 不过还有一个好消息，虽然我不能用DDR3的内存，但是我可以使用其他品牌、其他厂商、不容容量的DDR1 的内存，只要是DDR1的就可以更换。 内存升级换代了，主板也要做调整，否则就不能使用新的内存，这就是高耦合。 内存没有升级换代，那么就可以更换其他品牌、厂商和容量的内存，这就是低耦合。
可能你有点晕，怎么一回低一会高？ 先说低耦合吧。为什么可以更换其他品牌、厂商和容量的内存的内存呢？因为内存厂商和主板厂商，都准寻同一个标准（接口）——DDR（1代）。大家都准寻这个标准来生产，那么生产出来的就可以互相替换。我想升级内存可以更换容量，比如单条512K的内存和单条1G的内存。 那么到后来怎么又不行了呢？标准（接口）发生了变化。赖以生存的东东变了，于是就杯具了。
谈论耦合，目的是为了能够把一个大的模块分成几个小的模块，互相独立发展，但是之间又必须准寻一定的标准。也就是他们互相调用（或者单项调用）的方式。
就是这个标准要如何定义，各个模块如何实现，要达到什么样的程度。就拿上面的例子来说，想当初内存的标准为什么不直接定义成DDR3的形式？我对硬件不太了解，相必有其原因吧，可能是技术上的，可能是经济上的，也可能是盈利方面的。这个就不多说了，总之想要一步到位，一下子做的完美，几乎是不可能的。量力而行吧。
以上是我的拙见，让大家见笑了。欢迎多多指教。
============ 对于内聚，我还没吃透，就不说了。
赞同。pc机里的cpu是可以自己更换的，但是笔记本里的cpu是不可以自己更换的。那么对于用户来说，笔记本与cpu就是紧耦合，但是这个并不影响笔记本的销售。如果笔记本增加了可以自己换cpu的功能，也未必会提高自己的销量。
所以，耦合的高低，和接受程度，要好环境、客户的需求等因素，不能一概而论，更不能谈虎色变。
现在的市场，讲究的是开发速度，我对这方面也很感兴趣，做了一个自己的框架。http://www.cnblogs.com/jyk/archive/2011/01/05/1926869.html这是我的博客，我的一个思路，已经实现了。http://www.naturefw.com
这是系统介绍。
而不是指着代码硬要辩论说他是什么内聚什么耦合又或者是什么模式，
我看楼主要阐述的思想其实本质上和sp1234的没什么冲突
我并没有否认主板是一个耦合度很低的设计。请不要误会。不管是由于什么原因造成的，总之DDR1变成了DDR3就要换主板。这是事实。当然我并没有因为这个就否定主板是低耦合的。
寄托于抽象，我不反对，但是抽象变了呢？或者是自己水平不佳，一开始就没抽象好呢？不是万能的，都是有可能出现意料之外的。
模块化已经成为所有工程学科中广为接收的方法。模块化设计降低了复杂性
(参见13.4.3 节)、方便了修改(软件可维护性的关键方面)、并且通过鼓励系
统的不同部分的并行开发简化了实现。13.5.1 功能独立性功能独立性是模块化和抽象及信息隐藏概念的直接产物。Parnas[PAR72]
和Wirth[WIR71]在关于软件设计的里程碑性文献中提到了促进模块化的求
精技术，以后，Stevens，Myers 和Constantine[STE74]的工作巩固了这个概
念。
功能独立性是通过开发具有“专用”功能的模块和“反对”同其他模块
的过分交互而实现的，换句话说，我们希望将软件设计成每个模块完成需求
的一个特定子功能，并且从程序结构的其他部分观察时具有简单的接口。有
理由询问为什么独立性是重要的，因为功能可以被划分，并且接口简化了(考
虑由小组完成开发时的分支情况)，有效模块化的软件(例如，独立模块)更易
于开发。因为由设计/编码修改引起的副作用受到局限，错误传播被减小，以
及模块复用成为可能，因此，独立的模块更易于维护(及测试)。总而言之，
功能独立性是良好设计的关键，而设计又是软件质量的关键。
独立性是通过两项质量标准来衡量的：内聚和耦合。内聚是模块相对功
能密度的度量，耦合是模块间相对独立性的度量。
13.5.2 内聚
内聚是13.4.9 节描述的信息隐蔽功能的自然扩展。内聚的模块在软件过
程中完成单一的任务，同程序其他部分执行的过程交互很少，简而言之，内
聚模块(理想情况下)应该只完成一件事。
内聚可以用图13－6 所示的“谱系”来表示，尽管谱系的中段通常也是
可以接收的，但我们总是尽量争取高内聚。内聚的刻度是非线性的，也就是
说，低端内聚比中段内聚要“差”得多，而中段内聚几乎和高端内聚一样“好”，
在实际上，设计者不必关心对特定模块的内聚分类，而应该理解整体概念并
且在设计模块时应该避免低内聚。
为了说明(有些开玩笑的)谱系的低端，我们讲述下面的故事：
在六十年代后期，大多数DP 经理开始认识到模块化的价值，不幸的是，
许多现有的程序都是单块的－例如，20000 行没有文档的Fortran 程序加上2
500 行子程序！为了将一个大型计算机程序达到一种艺术境界，一位经理命
令她的员工对程序进行模块化，而这些工作要在“你的业余时间”完成。
在压力下，一名员工(天真地)询问每个模块的合适长度，回答是“75 行
代码”，然后，他得到了一只红色的笔和一把尺子，测量75 行源代码的线性
距离，随后在源程序清单上一条接一条地划上红色的线，每一条红线表示一
个模块的边界。这种技术就类似于去开发具有偶然内聚的软件！
执行一组彼此松散相关的任务的模块就称作偶然内聚，执行逻辑相关的
任务模块(例如，产生所有输出而不管类型的模块)就是逻辑内聚，当模块包
含着由于必须在相同时间段内执行而相关的任务时，该模块就表现为时间内
聚。
以一个低内聚为例子，如有一个工程分析包错误执行处理的模块，当计
算的数据超出预定义的边界时调用该模块，它执行下列任务：(1)根据初始计
算的数据，计算补充数据；(2)在用户的工作站上生成错误报告(以图形方
式)；(3)执行用户要求的跟踪计算；(4)更新数据库；以及(5)使选择后续处
理的菜单有效。虽然前面的任务是松散相关的，但是，每一项都是独立的功
能实体，并且最好作为独立的模块完成。将这些功能组合在单一的模块中只
会起到在修改上述任一处理任务时增加错误传播可能性的作用。
中度内聚在模块独立程度上是彼此接近的。当模块的处理元素相关，并
必须按指定顺序执行时，就存在过程内聚；当所有处理元素集中在某个数据
结构的一块区域上时，通信内聚就产生了。高内聚是以执行单独过程任务的
模块为特征的。
如前所述，确定内聚的精确级别是不必要的，重要的该是尽量争取高内
聚和识别低内聚，这样就可以修改软件设计来实现功能独立。
13.5.3 耦合
耦合是程序结构中模块相互连接的测度。同内聚类似，耦合可以用图13
－7 所示的谱系表示，耦合依赖于模块间接口的复杂性、引用或进入模块所
在的点、以及什么数据通过接口传递。
在软件设计中我们力争尽可能低的耦合。模块间的简单连接导致软件易
于理解，并且当错误发生于某个位置并在系统中传播时更少受“涟漪效应”
的影响。
图13－8 提供了不同类型耦合模块的例子。模块a 和b 是不同模块的子
模块，相互之间无关，因而没有直接耦合发生；模块c 是模块a 的子模块，
并通过常规的参数表来访问，数据通过该列表传递，只存在简单的参数表(例
如，传递简单数据；存在项的一对一对应)，这部分结构中就体现了低耦合(谱
系中的数据耦合)；当数据结构的一部分(而不是简单的参数)通过模块接口传
递时就会发现数据耦合的一个变体，被称作印记(stamp)耦合，这种情况出现
在模块b 和a 之间。
在中度耦合级别上，耦合的特性是在模块间传递控制。控制耦合在大多
数软件设计中非常普遍，如图13－8 所示，在这里，“控制标记”(在从属或
上级模块中控制决策的变量)在模块d 和e 之间传递。
当模块连接到软件外部环境上时会发生相对高度的耦合，例如，I/O 将
模块耦合到特定设备、格式和通信协议上。外部耦合是重要的，但应该局限
在结构中少量的模块上。高耦合还发生在许多模块引用一个全局数据区时。
共用耦合，就象这种模式的名称一样，显示在图13－8 中，模块c、g 和k
都访问一块全局数据区中的数据项(例如，一个磁盘文件、 Fortran COMMON
或C 语言中的外部数据类型)，模块c 初始化该数据目，以后模块g 重新计算
并更新该数据目，让我们设想出现了错误，并且g 错误地更新了该数据目，
再以后的处理中，模块k 读取该数据目，试图处理它并失败了，引起软件异
常中止。引起软件异常中止的表面原因是模块k，实际的原因在于模块g。在
具有很多共用耦合的结构中诊断错误是费时和困难的，然而，这并不意味着
使用全局变量就一定是“坏的”，它的含义是软件设计者应该注意共用耦合
的潜在后果，并特别注意防范这些后果。
耦合的最高层次，内容耦合，出现在一个模块使用在另一个模块的边界
中维护的数据或控制信息的情况下，其次，内客耦合出现在分支并跳转到模
块中间时，这种模式的耦合能够并且应该避免。
上面讨论的耦合模式的出现是由于设计决策是在开发程序结构时做出
的，然而，各种各样的外部耦合也可能在编码时引入，例如，编译器耦合将
源代码同编译器的特定(常常是不标准的)属性联系到一起；操作系统(OS)耦
合将设计和结果代码同操作系统的“钩子”联系到一起，而当OS 发生变化时
这会造成严重的破坏
这就是他的特点呀，想要深入吗？交钱先。另外，我的自然框架没有技术来推广吗？这个也不算是软文吧，我的一个想法。自然框架里的QuickPager分页控件，就涉及到耦合的问题，好多人都是这个分页控件耦合度很高。说一下我的想法。其实我觉得如果能够把主板的设计，主板接口设计，主板与内存、cpu等配件如何通讯的话，那么对以软件设计来说，也是一个很大的提高的。