[依赖和耦合关系.docVIP

依 赖 和 耦 合 关 系 1、依赖和耦合（Dependency and Coupling） （1）什么是依赖 Rose的帮助文档上是这样定义“依赖”关系的：“依赖描述了两个模型元素之间的关系，如果被依赖的模型元素发生变化就会影响到另一个模型元素。典型的，在类图上，依赖关系表明客户类的操作会调用服务器类的操作。” （2）什么是耦合 Martin Fowler在《Reducing Coupling》一文中这样描述耦合：“如果改变程序的一个模块要求另一个模块同时发生变化，就认为这两个模块发生了耦合。” [Fowler 2001] 注意： 从上面的定义可以看出：如果模块A调用模块B提供的方法，或访问模块B中的某些数据成员（当然，在面向对象开发中一般不提倡这样做），我们就认为模块A依赖于模块B，模块A和模块B之间发生了耦合。 耦合是依赖的同义词，被定义为“两个元素之间的一种关系，其中一个元素变化，导致另一个元素变化”。抽象耦合被定义为“若类A维护一个指向抽象类B的引用，则称类A抽象耦合于B”。 2、依赖是不可避免的 （1）“分而治之”的问题处理方法 对于复杂的系统，我们常常采用它划分成多个模块，这样将能够有效地控制模块的复杂度，使每个模块都易于理解和维护。 （2）“分而治之”的结果是产生依赖关系 一旦我们采用“分而治之”的处理方法后，模块之间就必须以某种方式交换信息，也就是必然要发生某种耦合关系。 如果某个模块和其它模块没有任何关联（哪怕只是潜在的或隐含的依赖关系），我们就几乎可以断定，该模块不属于此软件系统，应该从系统中剔除。 如果所有模块之间都没有任何耦合关系，其结果必然是：整个软件不过是多个互不相干的系统的简单堆积，对每个系统而言，所有功能还是要在一个模块中实现，这等于没有做任何模块的分解。 （3）依赖是不可避免的 因此，模块之间必定会有这样或那样的依赖关系，我们永远也不要幻想消除所有的依赖（耦合关系）。我们在类的设计时，应该首先考虑的是该类应该尽可能依赖不经常变化的“目标”-----比如，系统的API库或者框架中的组件-----试图令具体的、易变的模块依赖于抽象的、稳定的模块的基本原则。 在Java中，表示字符串的是具体内String。该类是稳定的，也就是说，它不太会改变。因此，直接依赖于它不会造成损害。 既然变化不可避免，我们所能做的就是处理好依赖关系，将变化造成的影响的波及范围尽量减小。 （4）我们所追求的是尽可能降低过强的耦合关系 “依赖”是和“变化”紧密联系在一起的概念。由于依赖关系的存在，变化在某处发生时，影响会波及开去，造成很多修改工作，这就是依赖的危害。 因为，过强的耦合关系（如一个模块的变化会造成一个或多个其他模块也同时发生变化的依赖关系）会对软件系统的质量造成很大的危害。 特别是当需求发生变化时，代码的维护成本将非常高。所以，我们必须想尽办法来控制和消解不必要的耦合，特别是那种会导致其它模块发生不可控变化的依赖关系。 （5）如何达到-----采用什么的策略或者方法 依赖倒置、控制反转、依赖注入等原则。 3、依赖倒置（DIP----Dependency Inversion Principle） （1）什么是依赖倒置----将依赖关系倒置为依赖接口 依赖倒置原则就是建立在抽象接口的基础上的。Robert Martin这样描述依赖倒置原则[Martin 1996]： 上层模块不应该依赖于下层模块，它们共同依赖于一个抽象。 抽象不能依赖于具体，具体依赖于抽象-----也就是“系统的核心逻辑依赖于具体的实现细在很多应用中，都需要存储。一个常见的解决是使用分层的方法，将应用中分为和，这种 （2）常规设计和实现方案中所反映出的问题 从上面的图中的所示的数据访问操作组件和数据连接组件之间的关系来看，两者产生了紧密的藕合关系。一旦有了任何变化，都有可能会受其影响需要改动。当然，如果只是两个类的话，这种依赖关系根本算不上什么问题然而，，和都会由不只一个类，并都有一定的复杂度，这时它们之间的这种依赖关系就会程序模块越来越多越来越复杂，复杂度如果不限制它们之间的联系，那模块间的依赖、程序的复杂度和开发维护的难度都会成指数上升。接口，其包含服务实现这个接口则调用接口中的服务来数据，两者都只依赖于接口。这样，到的依赖关系被接口。因为接口中只包含了服务，而不包括任何服务实现，所以接口的内容会很简单。在接口不变的情况下，和这两个模块都可以自由地进行修改而不影响到对方依赖关系也变得管理。核心逻辑依赖于具体的实现细节如果从角度来看中的设计，是的核心部分，而则可以看成是实现的细节设计核心逻辑依赖于具体的实现细节，当细节变化时，核心逻辑也会受到影响当时，。控制反转（Ioc----Inversion of Control） 1、消解框架和我们的