依赖倒置像金鱼，好看但难养

依赖导致是解耦的核心之一，但它就像金鱼一样，看着好看，缺很难伺候。

================

依赖倒置 - 面向接口编程。（是不是一下变得高大上了？）

依赖倒置的核心：模块之间的依赖通过抽象（抽象类、接口）产生

上一章我们聊了继承，这章聊实现。

我理解的面向接口编程

字面意思，是通过接口产生依赖关系。实现类不直接发生交互。那么接口是什么呢？

接口是规则的集合

接口设定了一系列的规则，面向接口编程就是 面向规则编程。

再简单说下什么是规则。规则就是类A你要给我提供getX方法和setX方法，至于你怎么实现，我不管。规则我给你定好了，你实现吧。

那么这样做的好处是什么呢？

就好比地球上大国的高层领导，领导和领导们之间玩的都是规则，他们在上层发号命令。下面的小兵兵们实现就好了，只有小兵兵们怎么做，他们才不管呢，这是小兵兵们需要考虑的问题。每一年的情况都不同，所以每一年同一个命令的实现方式也不同，作为小兵兵的要为上层考虑，不能让他们“劳心尽力”，考虑这些小问题。所以上次并不知道每一年他命令的实现都不同。这就保持了稳定！

看！面向接口编程的目的是实现解耦，解耦的目的是保持修改的最小化，保持稳定。

面向接口编程是不是太棒了？

说的永远比唱的好听。这回，我们从坏处开始讲：

面向接口编程的贯彻者：MVP架构

MVP应该是现有架构里，面向接口编程最彻底的了。M-V-P三层为了实现最大程度解耦，全部采用接口实现依赖。设想是好的，实际也是有好处的。但真正的实践者依然很少，因为它优点是那么诱人，但缺点是却是那么致命！！

人不是万能的，不可能提前想好所有的规则。需求也是多变的，不可能保持稳定。（虽然MVP就是应对需求多变的）

面对规则设定的不稳定，直接现象就是接口大规模变动。而更多时候，很可能是三层接口跟着变动。三层接口跟着变动的后果就是，三层的实现类需要跟着修改。你能想象这有多么痛苦吗？

当然必须要承认的是，一旦架构稳定下来，步入中后期维护，MVP带来的优点将会逐渐体现出来。就好像LOL里的后期英雄一样。

真实场景中的依赖倒置

其实不说MVP架构，真正的项目中，除了独立库以外，符合依赖倒置原则的地方也并不多。（后端架构不太清楚，但客户端至少是这样）。

毕竟接口的设计成本也是很大的，而业务需求的变动往往也有没有想象中那么大，直接修改实现类的成本有时反而是很小的。

所以实际项目中并没有必要一定遵循依赖倒置原则，考虑一下这真的是必须的吗？

但是在边写依赖库时，对门面的设计，还是要面向接口，对内部信息做隐蔽。

依赖倒置的好处

说了半天，依赖导致好像变成一个花瓶一样的东西。但他还是有很大好处的，只要我们注意使用就行。

• 一个被多处依赖的对象，应该以面向接口编程设计。

  一个被多处依赖的对象，如果需要修改，深入多个类修改的代价是非常大的。这个时候如果引入接口或抽象工厂模式，这样的问题就被完美解决了。

• 面向规则，屏蔽规则以外的东西。

  一个实现类除了接口所需的方法以外，还会有很多自己的公共方法，这些方法暴露给上层模块是不安全的，通过接口，则可以将这些不应该暴露的方法隐藏起来。

• 里氏替换

  接口依然适用于里氏替换，这将对软件设计提高很大的灵活度。

结论

从我个人的角度，是拒绝依赖倒置的大面积普及的。但我依然很喜欢依赖倒置，在一些规则稳定的场景，依赖倒置不失为一把解耦利器！！