松耦合，什么是软件松耦合依赖关系

本文目录一览

1，什么是软件松耦合依赖关系
2，八喜小子在Java中什么是松耦合高内聚
3，系统整合采用松耦合模式有什么意思
4，电力系统中松偶合名词解释
5，老是提到耦合耦合到底是什么意思松耦合是什么意思问
6，松耦合的简介

1，什么是软件松耦合依赖关系

假如你去麦当劳前台买可乐, 你可以把你和麦当劳工作人员想象为软件的两层或两个模块.那么你给服务员5块钱,然后他帮你打一杯可乐,你们之间是松耦合的,你们的接口就是5块钱,你只要给他钱,就不用管他是怎么拿杯子，从哪打的可乐.但是如果你给他5块钱,然后你要自己去取杯子,去找可乐机,自己排队, 那么你跟麦当劳就是紧密耦合的.这么说明白些了吗

额

什么是软件松耦合依赖关系

2，八喜小子在Java中什么是松耦合高内聚

这个其实是java面向对象的一种思想，我们程序员都想把程序写到这一步，但是，也只能做到近似。对高内聚，低耦合的理解内聚：一个模块内各个元素彼此结合的紧密程度耦合：一个软件结构内不同模块之间互连程度的度量(耦合性也叫块间联系。指软件系统结构中个模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，模块的独立性则越差，模块间耦合的高低取决于模块间接口的复杂性，调用的方式以及传递的信息。)

八喜小子在Java中什么是松耦合高内聚

3，系统整合采用松耦合模式有什么意思

松耦合系统通常是基于消息的系统，此时客户端和远程服务并不知道对方是如何实现的。客户端和服务之间的通讯由消息的架构支配。只要消息符合协商的架构，则客户端或服务的实现就可以根据需要进行更改，而不必担心会破坏对方。松耦合通讯机制提供了紧耦合机制所没有的许多优点，并且它们有助于降低客户端和远程服务之间的依赖性。但是，紧耦合性通常可以提供性能好处，便于在客户端和服务之间进行更为紧密的集成（这在存在安全性和事务处理要求时，可能是必需的）。

系统整合采用松耦合模式有什么意思

4，电力系统中松偶合名词解释

两个电感线圈之间存在互感，用耦合系数来描述两个线圈耦合的紧密程度。从电机和变压器的工作原理出发，我们希望耦合系数等于1（称为全耦合）。但是在某些场合也希望尽量减小耦合，例如大电流导线对周边建筑物内钢筋引起的涡流和感应发热，又例如同杆假设的双回线相互之间电磁耦合等。为了减小某些不希望存在的耦合，通常是采用“屏蔽”措施。我个人理解所谓“松耦合”就属于这一类耦合系数较低，但是对电力系统运行存在不良影响的电磁感应现象。

你好！简单说就是模块之间的依赖型和制约比较小，更改一个模块不会比较大的影响其他模块希望对你有所帮助，望采纳。

5，老是提到耦合耦合到底是什么意思松耦合是什么意思问

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

搜一下：看一些程序设计方面的书籍老是提到“耦合” 耦合到底是什么意思？松耦合是什么意思

6，松耦合的简介

最近，人们越来越热衷于比较应用程序交互的松耦合方法和紧耦合方法。造成这个趋势的主要技术原因是：使用UDDI(Universal Description, Discovery and Integration，通用描述、发现和集成)等标准，Web服务可以动态地发现和绑定到其他服务。而主要业务原因是：企业越来越需要灵活地处理业务流程的更改以及与合作伙伴的交互方式。松耦合系统的优点在于更新一个模块不会引起其它模块的改变。　　传统上，业务流程是在企业范围，甚至在企业的不同业务单元内开发。这些活动在详细的实时信息的帮助下进行管理。跨多个业务单元或跨企业的流程必须更加灵活，以应对各种各样的需求。在这种情况下，可能出现更多的不确定性：参与者及其角色不断变化，所需的交互类型也不断变化。在运营状况起伏不定的环境下，必须有一个松耦合架构，以降低整体复杂性和依赖性。松耦合使应用程序环境更敏捷，能更快地适应更改，并且降低了风险。除此之外，系统维护也更方便。在B2B领域，由于要求业务实体之间独立交互，因此松耦合显得尤为重要。业务合作伙伴之间的关系变化莫测，联合关系时而建立，时而又断绝，还需要在商业合作伙伴之间建立业务流程以满足市场的要求。两家公司在某一市场是合作伙伴，而在另一市场却可能是竞争对手。底层IT基础结构要适应这样的灵活性和独立性要求。理想情况下，业务关系应当互不影响：在建立新型业务关系时，不对已有的业务关系造成影响。为一个业务合作伙伴提供的功能或许不应当供给另一个合作伙伴；与一个业务合作伙伴相关的更改不应对其他合作伙伴造成影响。一个商业合作伙伴不应为了等待一个同步响应，而阻塞另一个合作伙伴。IT系统的可用性也不应依赖于业务合作伙伴IT系统的技术可用性。