设计模式： 依赖倒置 DIP

dependency inversion principle

高层次的模块不应该依赖 于 低层次的模块，两者都应该依赖于 抽象接口。

代码的设计，就应该像操作系统的设计，高层次的模块，比如APP，不依赖于这个系统是linux 还是windows的具体实现，而仅仅依赖于操作系统这个抽象接口，这样的话，APP业务逻辑的更迭，完全不用费心去考虑，面对不同的操作系统的具体实现，我们要做什么适配，这个为了适配不同平台的考虑完全是浪费精力，效率也低。所以，我们要设计一个模块，向外提供一个抽象的接口，那么外部的模块就容易和我们配合。

抽象的接口不应该依赖于具体的实现，而具体的实现依赖于抽象的接口

这个可能和我们常见的【熟能生巧】成为反比，平时我们设计了很多具体实现，才慢慢发现，其中的道，于是后来就抽象出来一种灵巧的方式，完成我们的工作；

但是在快速，协作的开发环境中，我们最好的方式是： 先抽象好，再去落地具体实现。

总结：

我们设计抽象接口的时候，不应该是凭借众多具体的实现，再慢慢提取出一个现有众多实现的一个抽象，而是我们先提出一个约定，也就是先提出一个抽象的接口，（这个接口可能不能满足具体实现的某个功能，但是接口隔离原则允许我们这样做），然后我们再根据这个抽象接口去设计具体的实现；这样做的好处就是，我们后期只需要面对一个单独的抽象接口进行业务的更迭，变化，而不用去考虑业务的改变对已有代码的具体实现的影响。具体的实现在约定的框架下做任何变动，不会影响更上层的设计。