本文意在让读者意识到软件工程中，结合部问题的重要性和普遍性，尝试探讨解决思路。
高内聚低耦合，是面向对象开发方法中一个重要的设计原则，对此我没有异议。但是，如果扩大软件工程的内涵，将整个工程从业务拓展到最终提交全部纳入到管理范畴当中，我们将发现这句话不仅有局限性，而且很容易误导我们，有意识无意识地回避结合部存在真空的问题，可谓害人不浅。
本文后面附件《软件工程的耦合》，大家也可以参考。
当我们用 "软件" + "结合部"两个词联合搜索谷歌的时候，能够得到满意结果几乎是零。最直观的原因可能是我们使用的关键词不正确，还有可能是根本不存在问题，当然还有一种可能就是，我们一直努力回避这两个词在一起出现的问题。但是不管是以上哪种结果，事实却一再提醒我们，软件工程中结合部往往是发生问题最多，消耗时间最长，导致失败最直接的元凶。 还是举几个例子吧，都是我曾经亲身经历过的。
例1：某著名网络游戏公司，研发新一代网络社区及其相关游戏系统。需求分析是通过以往版本积累以及用户潜在需求调研综合讨论后完成的。涉及到不仅是新颖的图形界面和操作体验，还融汇进大量增强用户粘性和用户之间交换的个人成长和集体成长的线索。通过概要设计阶段后，进入代码实施阶段，庞大的系统被依次肢解成为若干看得见的部分，并开始代码编程过程，前期需求分析人员同步跟进各个项目组，积极配合细化需求。经过若干月的代码攻坚后，系统大模样已经出来，新颖的图形界面和方便快捷的操作体验确实令试用者感觉耳目一新。但是，原发设计中加强用户粘性的个人成长和集体成长部分，被简化成几个定义和查询显示的界面，与初始设想大相径庭。再次追索重现研发过程才发现，由于这两个部分涉足几乎所有肢解后的每个部分，因此被相互推脱或者是误解给忘掉了。进一步究其根本的过程中，我们发现即便是没有误解或者责令到位也很难达到预期。因为，大家在肢解项目的时候，就没有重视这些结合部可能潜在的问题，因为肢解本身就会导致群龙无首的平行运作状态，所有的结合部都因此被一些简单的数据结构或者参数传递所替代。等到项目组意识到新系统在实现上较原发意图大打折扣的时候，再往现有系统追加功能已经发现为时已晚，所要付出的人月成本几乎与前期规模相当。
例2：某网络软件技术公司，主要从事为各种行业用户定制研发适合的管理系统。有一次，市场拓展人员兴致勃勃找到研发中心，说目前谈下一个可以使公司有机会介入出版行业的项目，属于新闻出版总署牵头，涉及到各个出版社邮购管理的业务。项目很急，希望尽快投入力量研发。公司分析后认为行业前景看好，并且在核心管理需求方面与公司既有的产品有很大重叠，立刻拍板立项，组织人力推进。项目启动后，首先是需求调研，马上遇到的问题是项目发起方新闻出版总署不能完全代表最终用户需求，绝大部分基础数据又来源于各个出版社，入驻总署推介的出版社展开调研配合程度远没有总署激情高，调研结果可想而知。这还不是最大的问题，由于当时互联网还刚刚起步，搜索引擎也没有现在先进，很难通盘了解潜在对手的情况。在需求调研和分析急于交付设计的驱动下，设计和代码就着有限的需求进行研发。等原型交付几个单位试用的时候，才突然发现专业领域存在的竞争对手，其产品复杂程度远远超乎调研者的需求分析。本来可以在出版物管理专业部分照抄对手产品，整合进自身既有管理系统优势，外加强大的行政干预人脉，做到在我们不熟悉的专业领域不丢分，我们熟悉的通用领域加满分的完美情况，就因为软件工程研发的各道结合部出现问题而险些折戟沉沙。
例3：还是例2的公司，公司通过人脉有机会为一个准备上市的旅游公司研发管理信息系统。其上市公司由多个酒店、旅行社等优质资产整合而成。经过长达一个月的摸底调研后发现，该公司下属这些酒店。旅行社都在运行着各自的管理系统，说服他们放弃现有系统也并非难事，只是对于新介入旅游酒店行业的我们公司来说，能够拿出一整套酒店管理和旅行社管理系统，需要投入巨大的人力物力，当然如果成功开发出来，收入自然不菲。经过仔细分析后，我们认定造成该上市公司决心更换管理系统的初衷就是为了高层决策提供依据，而各自系统结合部成为制约总经理查询的最大障碍。因此，我们公司从整体设计思路转向结合部整合，瞄准各个系统的核心数据查缺补漏，在经营决策层再造了一个数据挖掘平台，从而顺利完成该项目。
上面举的例子都是软件工程研发过程中，结合部出现的问题，具有一定的普遍性，虽然不全面，但是具有代表性。在充分认识到其存在的可能性后，很多有经验的项目管理者都会找到规避的方法。加强沟通就是一种常用的做法，不过这个词往往被用在失败总结会上的几率更高一些。我个人更赞成形成规范、制度并严格遵守更为稳妥。
那么怎么发现结合部存在问题，如何解决呢？现在让我们放开思路，看看身边还有很多结合部的例子，希望能够从中得到启发：
1.城乡结合部：
这恐怕是这些年城市发展经常争论不休的问题，市政管线到位之后，仍旧存在交通不够便利，环境污染脏乱差等等问题。
这说明，忽视结合部的开发和利用，再好的城市、在美的农村景色也会被不和谐的部分抹黑。
2.行政区划的三不管地区：
典型的就是我们党在建国以前，就是靠着在这些边区发展，保存和休养生息自己的武装力量，才在解放全国的斗争中取得了一个有一个胜利。
这说明，善于发现结合部的开发与利用，能够给我们带来意想不到的好处。
3.人体的运动器官：
手掌和前臂的结合部是手腕，小腿和大腿的结合部是膝盖。这些结合部都是由体积相对狭小的多块骨骼排列和坚韧的关节囊包裹而成。
这说明，作为结合部虽然不是主要功能的承担者，但是在完成功能转化和衔接中，可以起到很重要的作用。同时再次显现出结合部的设计思路不能照搬功能部的那套思想。完成联络与沟通的同时，自身多态也是很重要的需求存在。
4.地铁列车车厢：
早期地铁车厢是一个一个的车厢组成，之间通过挂钩和馈线连接。与近几年新车厢相比，一节一节的空间被大通道似的敞亮空间所替代。
原来受限于密封工艺制造的限制，在新材料新工艺下得到突破的同时，有限承载空间大幅增加。为此所做的专门改进不仅提高了承载能力，还增加了舒适度。
如何有效规避结合部的风险并发挥结合部潜质，有待大家共同努力，我在此权作抛砖引玉地提一些个人想法：
1.属于工序间形成的结合部，可以考虑参考水管接头的形式，相互重叠允许冗余适度存在。
2.属于功能划分形成的结合部，可以考虑多层次结构形式，为跨功能的部分提供通路。
3.属于层次划分形成的结合部，可以考虑通过增加实现时序的参照，从而达到各部分协调统一。
4.属于松散型各自独立没有结合部，可以考虑进行数据挖掘，用小的成本换取大的效果。
限于个人认识能力有限，结合部问题粗说如是。经验告诉我们，结合部问题发现越早，解决越好；利用结合部越好，越能给软件带来事半功倍的效益。
《软件工程中的耦合》
简单地说，对象之间的耦合度就是对象之间的依赖性。指导使用和维护对象的主要问题是对象之间的多重依赖性。对象之间的耦合越高，维护成本越高。因此对象的设计应使类和构件之间的耦合最小。
就是依赖性，相关性吧！！！
有软硬件之间的耦合，还有软件各模块之间的耦合。
耦合性是程序结构中各个模块之间相互关联的度量.它取决于各个模块之间的接口的复杂程度、调用模块的方式以及哪些信息通过接口.一般模块之间可能的连接方式有七种,耦合性由低到高分别是:非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合。
耦合是对一个软件结构内各个模块之间互连程度的度量。
内聚标志一个模块内各个元素彼此结合的紧密程度，它是信息隐蔽和局部化概念的自然扩展。
1． 什么是内聚？什么是耦合？
内聚是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做一件事。它描述的是模块内的功能联系； 耦合是软件结构中各模块之间相互连接的一种度量，耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。
2． 内聚分为哪几类？耦合分为哪几类？
内聚有如下的种类，它们之间的内聚度由弱到强排列如下：
（1） 偶然内聚。模块中的代码无法定义其不同功能的调用。但它使该模块能执行不同的功能，这种模块称为巧合强度模块。
（2） 逻辑内聚。这种模块把几种相关的功能组合在一起， 每次被调用时，由传送给模块参数来确定该模块应完成哪一种功能
（3） 时间内聚
（4） 过程内聚
（5） 通信内聚
（6） 顺序内聚
（7） 功能内聚
耦合可以分为以下几种，它们之间的耦合度由高到低排列如下：
（1） 内容耦合：如果发生下列情形，两个模块之间就发生了内容耦合
1. 一个模块直接访问另一个模块的内部数据;
2. 一个模块不通过正常入口转到另一模块内部;
3.两个模块有一部分程序代码重迭(只可能出现在汇编语言中);
4.一个模块有多个入口。
（2） 公共耦合：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
（3） 外部耦合： 一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。
（4） 控制耦合：如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。
（5） 标记耦合：一组模块通过参数表传递记录信息，就是标记耦合。这个记录是某一数据结构的子结构，而不是简单变量。
（6） 数据耦合：一个模块访问另一个模块时，彼此之间是通过简单数据参数 (不是控制参数、公共数据结构或外部变量) 来交换输入、输出信息的。
（7） 非直接耦合：两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的。
