松耦合的简介

最近，人们越来越热衷于比较应用程序交互的松耦合方法和紧耦合方法。造成这个趋势的主要技术原因是：使用UDDI(Universal Description, Discovery and Integration，通用描述、发现和集成)等标准，Web服务可以动态地发现和绑定到其他服务。而主要业务原因是：企业越来越需要灵活地处理业务流程的更改以及与合作伙伴的交互方式。松耦合系统的优点在于更新一个模块不会引起其它模块的改变。传统上，业务流程是在企业范围，甚至在企业的不同业务单元内开发。这些活动在详细的实时信息的帮助下进行管理。跨多个业务单元或跨企业的流程必须更加灵活，以应对各种各样的需求。在这种情况下，可能出现更多的不确定性：参与者及其角色不断变化，所需的交互类型也不断变化。

在运营状况起伏不定的环境下，必须有一个松耦合架构，以降低整体复杂性和依赖性。松耦合使应用程序环境更敏捷，能更快地适应更改，并且降低了风险。除此之外，系统维护也更方便。在B2B领域，由于要求业务实体之间独立交互，因此松耦合显得尤为重要。业务合作伙伴之间的关系变化莫测，联合关系时而建立，时而又断绝，还需要在商业合作伙伴之间建立业务流程以满足市场的要求。两家公司在某一市场是合作伙伴，而在另一市场却可能是竞争对手。底层IT基础结构要适应这样的灵活性和独立性要求。理想情况下，业务关系应当互不影响：在建立新型业务关系时，不对已有的业务关系造成影响。为一个业务合作伙伴提供的功能或许不应当供给另一个合作伙伴；与一个业务合作伙伴相关的更改不应对其他合作伙伴造成影响。一个商业合作伙伴不应为了等待一个同步响应，而阻塞另一个合作伙伴。IT系统的可用性也不应依赖于业务合作伙伴IT系统的技术可用性。

我的理解是：软件设计中的“耦合”指，两个功能函数之间的依赖程度。

比如，你设计的一个程序，需要你编写10个功能函数来实现。如果这10个功能中，有9个功能都要调取第10个功能函数X10，那么，当你在修改X10时，你就要考虑修改完成后，是否会对其它9个功能函数有影响，为了查看是否有不好影响，你就要对其它9个功能函数，一个一个进行测试。所以，为了避免产生这种后期修改的劳动量。就提倡【松耦合】，就是，功能函数之间，尽量依赖程度不要太高。否则，修改完一个底层函数后，会对多个上层函数，进行大量的测试。

【松耦合】的方法，一般是底层函数，功能尽量单一，尽量避免修改底层函数。功能相近的函数，可以设计2个以上，不要为了减少代码量，把一个函数的功能设计的太多。

---