背景介绍
这是我的《架构整洁之道》系列的第十篇，这一篇我们将一起学习 DIP 依赖反转原则～
高层策略性的代码不应该依赖实现底层细节的代码，恰恰相反，那些实现底层细节的代码应该依赖、高层策略性的代码。
《架构整洁之道》系列：
DIP 依赖反转原则
依赖、反转原则(DIP)主要想告诉我们的是，如果想要设计一个灵活的系统，在源代码层次的依赖、关系中就应该多引用抽象类型，而非具体实现。
显而易见，把这条设计原则当成金科玉律来加以严格执行是不现实的，因为软件系统在实际构造中不可避免地需要依赖到一些具体实现。
我们主要应该关注的是软件系统内部那些会经常变动的具体实现模块，这些模块是不停开发的，也就会经常出现变更。
稳定的抽象层
我们每次修改抽象接口的时候，一定也会去修改对应的具体实现。但反过来，当我们修改具体实现时，却很少需要去修改相应的抽象接口。所以我们可以认为接口比实现更稳定。
也就是说，如果想要在软件架构设计上边求稳定，就必须多使用稳定的抽象接口，少依赖多变的具体实现：
- 应在代码中多使用抽象接口，尽量避免使用那些多变的具体实现类
对此，我们通常会选择用抽象工厂(abstractfactory)这个设计模式
- 不要在具体实现类上创建衍生类
- 不要覆盖(override)包含具体实现的函数
- 应避免在代码中写入与任何具体实现相关的名字，或者是其他容易变动的事物的名字
工厂模式
如果想要遵守上述编码守则，我们就必须要对那些易变对象的创建过程做一些特殊处理。在大部分面向对象编程语言中，人们都会选择用抽象工厂模式来解决这个源代码依赖的问题。
如下图，
Application类是通过Service接口来使用ConcreteImpl类的。 然而，Application类还是必须要构造ConcreteImpl类实例。于是，为了避免在源代码层次上引入对ConcreteImpl类具体实现的依赖，我们现在让Application类去调用ServiceFactory接口的makeSvc方法。这个方法就由ServiceFactoryImpl类来具体提供，它是ServiceFactory的一个衍生类。该方法的具体实现就是初始化一个ConcreteImpl类的实例，并且将其以Service类型返回。
上面的例子中，具体实现组件的内部仅有一条依赖关系，这条关系其实是违反 DIP 的。这种情况很常见，我们在软件系统中并不可能完全消除违反 DIP 的情况。通常只需要把它们集中于少部分的具体实现组件中，将其与系统的其他部分隔离即可。
绝大部分系统中都至少存在一个具体实现组件一一我们一般称之为
main组件， 因为它们通常是main函数所在之处。上面的例子中，main函数应该负责创建ServiceFactoryimpl实例，并将其赋值给类型为ServiceFactory的全局变量，以便让Application类通过这个全局变量来进行相关调用。
// TODO:我没有完全理解上述例子，抽象工厂模式单独出一篇文章
中间的那条曲线代表了软件架构中的抽象层与具体实现层的边界。在这里，所有跨越这条边界源代码级别的依赖关系都应该是单向的，即具体实现层依赖抽象层。
上图中的这条曲线将整个系统划分为两部分组件：抽象接口与其具体实现。
- 抽象接口组件：包含了应用的所有高阶业务规则
- 具体实现组件：包括了所有这些业务规则所需要做的具体操作及其相关的细节信息
DIP 被称为依赖反转原则的原因：控制流跨越架构边界的方向与源代码依赖关系跨越该边界的方向正好相反，源代码依赖方向永远是控制流方向的反转
结束语
在系统架构图中，DIP 通常是最显而易见的组织原则。我们在后续会把工厂模式章节图片中的那条曲线称为架构边界，而跨越边界的、朝向抽象层的单向依赖关系则会成为一个设计守则一一依赖守则。
最后
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
少年向来不识天高地厚
放眼处皆自负才高八斗
虽是自命风流
倒也坦诚无忧
我爱这样的少年
谦和而狂妄
骄傲又坦然☀️
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
