DIP:依赖反转原则

抽象不应该依赖细节，细节应该依赖于抽象。高层模块不应该依赖于底层模块，都应该依赖的抽象。

依赖反转原则主要想告诉我们的是，如果想设计一个灵活的系统，在源代码层次的依赖关系中就应该多引用抽象类型，而非具体类型。

• 稳定的抽象层
  每次修改抽象层的时候，一定也会去修改对应的具体实现。但是反过来，当我们修改具体的实现的时候，却很少需要去修改相应的抽象接口。所以接口比实现更稳定。

依赖守则

应在代码中多使用抽象接口，尽量避免使用那些多变的具体实现类。

抽象工厂设计模式

不要在具体实现类上创建衍生类

面向对象的编程中，继承关系是所有以前源代码依赖关系中最强的、最难被修改的，所以我们对继承的使用应该格外小心。

不要覆盖包含具体实现的函数

调用包含具体实现的函数通常意味着引入了源代码级别的依赖。即使覆盖了这些函数，也无法消除这些依赖关系。控制依赖关系的唯一办法就是使用抽象函数，然后再为该函数提供多种具体实现

应避免在代码中写入与任何具体实现相关的名字，或者是其他容易变动的事务的名字。

创建对象为例

我们必须对那些易变对象的创建过程做一些特殊处理，创建对象的操作都避免不了需要在源代码层次上依赖对象的具体实现。在大部分面向对象编程语言中，人们会选择用抽象工厂模式来解决这个源代码依赖的问题。

抽象工厂模式管理依赖关系

Application类通过Service接口来使用ConcreteImpl类的。然而Application类还是必须要构造ConcreteImpl类实例。为了避免在代码层次上对引入ConcreteImpl类具体实现的依赖，现在让Application类去调用ServiceFactory接口的makeSvc方法。这个方法就由ServiceFactoryImpl类具体提供，它是ServiceFactory的一个衍生类。ServiceFactoryImpl类中makeSvc的具体实现就是提供一个ConcreteImpl类的实例。

图中那条曲线表示软件架构中抽象层与具体实现层的边界。这里所有跨越这条边界的代码级别的依赖关系都应该是单向，即具体实现层依赖抽象层。
这条曲线将整个系统划分为两部分组件：抽象接口与其具体实现。抽象接口组件中包含了应用的所有高阶业务规则，而具体实现组件中则包含了所有这些业务规则需要做的具体操作及其相关细节信息。

这里控制跨越架构边界的方向与源代码依赖关系跨越该边界的方向正好相反，源代码依赖方向永远是控制流方向的反转。