耦合供水的具体 *** 作程序及原理是什么谢谢。

耦合供水即2台以上消防车（泵）的串联，可提高水泵的扬程， *** 作时一般将功率大的消防车靠近火场（后车），功率小的靠近水源（前车），前车供水通过集水器直接打到后车的水泵内，注意后车挂联泵，打开出水阀门（切忌！否则后车泵很容易损坏）正常供水，前车加压要缓慢，到一定压力后稳压，此时后车开始缓慢加压，通常后车加压应稍大于前车，最后一辆车加压后余压叠加，不得超过该车的额定工作压力，停泵顺序和加压顺序相反。只要 *** 作规范耦合供水对车泵影响不大，但这种供水方法技术含量较高，产生的水压较大，危险性也较大，需谨慎 *** 作，不可盲目进行！

俺帮你在百度里查到的：对于开发者而言，耦合原则表示程序中单个的模块应该尽可能的独立。

处理一个模块时，不应该依赖另一个模块的内部工作。

内聚原则是指，在一个给定的模块内部，所有的代码应该只完成一个单个的目标。

IT界有一句很著名的口号：强内聚、松耦合。

即使是最初级的程序员，在常常的被教导中，他也了解了这句口号的含义：我们的程序要模块化，模块要完成明确的一组关联的服务功能，要求它的各部分是相关的、有机组合起来是完整体（外部程序来看黑盒子），模块的内部各成分之间相关联程度要尽可能高（强内聚）；而模块与模块之间又要求是可分拆的、少依赖的（松耦合）。

人们易于实现强内聚的模块，例如：一个函数实现一个独立的功能，这就是强内聚。

人们不易实现松耦合，因为，孤独的模块毫无意义，只有模块间的相互协调地工作，才能实现系统的目的。而对于模块间的相互关系的设计，没有一定的经验是难以把握。耦合的强度依赖于：（1）一个模块对另一个模块的调用；（2）一个模块向另一个模块传递的数据量；（3）一个模块施加到另一个模块的控制的多少；（4）模块之间接口的复杂程度。等等。

当然，“强内聚、松耦合”也是有矛盾的，如：内聚性越强，则要求的函数越多（每个函数只作一件“事”），这样，将它们组合成“大”的功能，也就越复杂，就不可能达到松耦合。因此，应在二者之间作出平衡与折衷的选择，这也体现程序员的水平。从系统论的角度来看，系统是有层次的，即系统可以分为子系统，模块可分为子模块，“强内聚、松耦合”的“度”的把握，应结合系统的次层性来考虑，即通常应在层次性上作出折衷，如：模块内子程序（下一个层次上）应共享数据（有一定的耦合度），而减少全局变量能降低子程序性间的耦合性。

面向对象的语言进一步强化了“强内聚、松耦合”，类的封装性既强调了相关内容（数据及其 *** 作）的内聚，又强调了类的独立性和私密性。而类的继承性以及友元等，就是在松耦合的原则下规范了类之间的关联关系。类与类之间通常通过接口的契约实现服务提供者/服务请求者模式，这就是典型的松耦合。

“强内聚、松耦合”对于程序编写分工、程序的可维护性以及测试都有重要的关系，如：从设计角度来看，在“强内聚、松耦合”的指导下进行的设计得到的程序模块，符合项目管理的WBS（工作分解结构）的要求，其相对独立的模块可以分配到具体的程序员进行开发，另外，程序编码外包也必须建立在这种原则的设计之下；从程序生命期角度来看，它有利于提高程序质量，特别是方便于程序的日后维护，即程序模块的相对独立性是可维护性的保证；再从测试角度来看，符合“强内聚、松耦合”的程序，易于对局部（模块）进行黑盒测试，也易于编写测试用的“桩”和“驱动”。

“强内聚、松耦合”也是对组织结构的要求，项目组分为几个小组（正式的或非正式的），各小组的工作应是高度相关的，各小组之间的工作应尽量是较少相关或有明确的接口，从而减少沟通成本。其实，“强内聚、松耦合”是系统中应遵守的普遍原则，我们在许多领域都可以找到它的应用。

“强内聚、松耦合”是我们不得不念的“三字经”，我们一定要念好它。

耦合就是程序中的一部分跟其他部分之间的关系。

软件工程有一条铁律“高内聚、低耦合”：

1、模块只对外暴露最小限度的接口，形成最低的依赖关系；

2、只要对外接口不变，模块内部的修改，就不得影响其他模块；

3、删除一个模块，应当只影响有依赖关系的其他模块，而不应该影响其他无关部分。

以上就是关于耦合供水的具体 *** 作程序及原理是什么谢谢。全部的内容，包括:耦合供水的具体 *** 作程序及原理是什么谢谢。、计算机的模块的内聚程度和模块间的耦合程度是什么啊！、Java耦合度的问题！等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！