依赖倒置原则

        依赖倒置原则，应该从两个方面来理解，一是OOD（面向对象的设计），一是软件结构。

        对于OOD，我想我们很容易理解为什么要使用它。首先，接口和实现分离给我们使用该原则提供了前提条件；为什么这么说呢？接口和实现分离这种设计方法应该已经得到验证是正确的，并且几乎在各种设计中都是有效而良好的。所以我们在设计中，尽量都使接口和实现分离，这样，我们也就得到了一个抽象的接口和一个具体的实现，并且实现继承接口，有了该现实的存在，我们对于接口存放的位置就可以重新定义了，我们可以把接口放在使用方，也可以把接口放在实现方，而依赖倒置原则则要求把这个接口（或者是抽象类）放在使用方，而所有实现该接口的类都可以互相替换，而对使用方透明。一旦我们把接口和使用方结合，并且要求提供服务的类（或模块）都要实现该接口，才能被使用方使用，我们就是在用“依赖倒置”原则了。

        其次，“依赖倒置原则”产生的一个结果是——具体依赖与抽象，而不再有依赖于具体的关系存在，这样就使整个接口具有了很大的灵活性，因为我们知道一般抽象是不变的，而具体是易变的，要是OO设计具有很大的灵活性，就需要做到大家都依赖于抽象的东西，而利用抽象隔离具体类之间的关系，这样使得“具体”的任何改动都可以在局部范围内实现，而不影响其它的结构。下图是一般的“依赖倒置原则”的使用图：

       下面，我们从软件结构设计上来看看“依赖倒置原则”的使用。现在的软件结构一般都是分层的，这是结构化软件设计方法带来的直接后果，而且和我们的普通思维形式是相符的。下层通过接口向上层提供服务，上层使用下层的接口使用下层提供的服务。这样就导致了策略实现依赖于机制。下层的任何改动都会直接影响到上层的策略实现，并且这种影响是可传递的。这样的情况引起了一系列负面的影响，比如在软件后期，我们一般不再去考虑更改底层的实现机制，因为这种更改带来的颠覆效果是不可想象的，会给项目带来毁灭性的打击；在多个系列的产品中，往往由于某些底层环境的不同，必须要修改底层机制，这样带来的工作量是不可想象的，因为它将会牵扯到上层策略的实现，而更改上层策略，是大家都不愿意看到的。这些问题的解决方案都将由“依赖倒置原则”提供。

       从现在来看，在很多领域软件中，上层策略的可移植性要远远重要于下层机制的可移植性，而上面提到的这种分层依赖结构直接导致上层策略在大部分情况下是不可移植的，因为要使它运行于不同的环境，不同的机制之上，是很困难的。那么我们要怎样解决这中情况呢？“依赖倒置原则”给了我们颠覆这种结构的理由和方法。理由是，上层策略的可移植对于开发通用的软件策略是非常必要的，而且可以在很大程度上节省工作量。下面我们将着重讲述方法。

       我们现在要做的不是让上层策略依赖于下层机制，而是在上层策略中本身包含了一组接口，上层策略就是利用这组接口进行实现的，而在它运行时需要一个实现了这组接口的底层机制做为支撑。这样我们就可以实现多个实现了该组接口的底层机制，来支持上层策略，并且这些底层机制是可以互换的，因为它们都提供了上层策略所需要的接口实现。这种方法看起来好像是下层机制依赖于上层策略了，所以它是依赖倒置的。这种设计方式也就解决了上面提到了那些问题。同一个策略可以在不同产品间平滑的移植，只要每个产品的底层机制都提供了它所需要的接口就可以了。

       当然，这个原则并不适用于所有情况，比如你被要求实现一个可移植的底层库，你当然不能使用它，否则你将无法工作。任何东西都有它的两面性，其实也不能说是两面性，因为它们都有自己擅长的地方和自己的短处，就如同人一样——人无完人。所有我们在使用任何方法、设计、模式时都要先问问自己，这个东西到底合不合适在这里使用，而不能为了用它而用它，这样将导致灾难性的结局。