对于设计原则——依赖倒转原则的一些个人理解

　　依赖倒转原则

　　什么是依赖倒转原则呢?

　　先举个例子，用造汽车举例子：

　　假如，造汽车的第一步是：造车轮

　　第二步是：根据车轮的大小造车底

　　第三步是：根据车底的大小造车身

　　最后一步是：根据车身的大小造出汽车。

　　那么这个过程中的依赖关系是：汽车依赖于车身的设计，车身依赖于车底的设计，车底依赖于车轮的设计。

　　粗略的看，这样的设计逻辑是没有问题的，各部分“零件”都互相依赖着，最后也能够把汽车组装成功，可是，这样的设计逻辑存在一个很大的问题，是什么呢?

　　——可维护性差

　　假如，现在和你们造汽车的工厂对接的客户说，我要求现在生产的汽车轮胎能够大个尺寸，那么就会有一个很严重的问题，就是要重新的设计车底，车身，汽车，这可以说是“牵一发而动全身”。

　　那么这个时候，如果我们换一种思维，先造汽车，再造车身，其次造车底，最后造车轮。这样子的话，如果造汽车的依赖关系就倒转过来了，变成了：车轮依赖于车底的设计，车底依赖于车身的设计，车身依赖于汽车的设计。

　　这时候要是改动轮子的话是不是就不需要改动汽车了?嗯…没错，粗略看过去是这样的，可是，还是有问题啊，如果我要直接改动汽车呢?那不是还是得全部都要改动?是的，没错，全部都要改动。

　　那我举上面的例子有什么用呢?嗯，有大用哦;网上百度一波，依赖倒转原则它的概念是：

　　1：高层模块不应该依赖于底层模块，两者都应该依赖于其抽象。

　　2：抽象不应该依赖具体实现，具体实现应该依赖抽象(看接口和实现类的关系)。

　　第一条概念说两者依赖于其抽象，那么在上面的造汽车，不管是从轮子(底层)开始，还是汽车(高层)开始都是从具体实现下手的，所以上面的举例不是依赖倒转原则。

　　其依赖倒转的核心思想是：面向接口编程

　　接下来造汽车的例子我就放在编程中说了：

　　首先，要创建四个接口，分别是，轮子，车底，车身，汽车。这四个接口里各自约定一些方法，比如说轮子的接口中，写一个带参的轮子尺寸方法。然后比如造汽车，造的是小轿车轮子的话，那么写一个实现这个接口的实现类，类名是小轿车车轮。要是现在突然又有新的需求，要造卡车轮子，那再写一个实现类来实现这个车轮的接口即可，其实这里用到了一个其他的原则(开闭原则：对修改关闭，对扩展开放)，接口中的方法呢，是之前约定好的东西，是不允许修改的，这里的不允许不是指真的不允许，而是有悖于设计原则的开闭原则，一个简单又好记的方法就是：接口的存在最主要的目的就是为了便于扩展、和维护。

　　总之，依赖倒转原则是针对接口的，高层模块和底层模块都是依赖于抽象(接口)的。

​