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

依赖倒转原则

什么是依赖倒转原则呢？
先举个例子，用造汽车举例子：
假如，造汽车的第一步是：造车轮
第二步是：根据车轮的大小造车底
第三步是：根据车底的大小造车身
最后一步是：根据车身的大小造出汽车。
那么这个过程中的依赖关系是：汽车依赖于车身的设计，车身依赖于车底的设计，车底依赖于车轮的设计。
粗略的看，这样的设计逻辑是没有问题的，各部分“零件”都互相依赖着，最后也能够把汽车组装成功，可是，这样的设计逻辑存在一个很大的问题，是什么呢？
——可维护性差
假如，现在和你们造汽车的工厂对接的客户说，我要求现在生产的汽车轮胎能够大个尺寸，那么就会有一个很严重的问题，就是要重新的设计车底，车身，汽车，这可以说是“牵一发而动全身”。
那么这个时候，如果我们换一种思维，先造汽车，再造车身，其次造车底，最后造车轮。这样子的话，如果造汽车的依赖关系就倒转过来了，变成了：车轮依赖于车底的设计，车底依赖于车身的设计，车身依赖于汽车的设计。
这时候要是改动轮子的话是不是就不需要改动汽车了？嗯…没错，粗略看过去是这样的，可是，还是有问题啊，如果我要直接改动汽车呢？那不是还是得全部都要改动？是的，没错，全部都要改动。
那我举上面的例子有什么用呢？嗯，有大用哦；网上百度一波，依赖倒转原则它的概念是：
1：高层模块不应该依赖于底层模块，两者都应该依赖于其抽象。
2：抽象不应该依赖具体实现，具体实现应该依赖抽象（看接口和实现类的关系）。
第一条概念说两者依赖于其抽象，那么在上面的造汽车，不管是从轮子（底层）开始，还是汽车（高层）开始都是从具体实现下手的，所以上面的举例不是依赖倒转原则。
其依赖倒转的核心思想是：面向接口编程
接下来造汽车的例子我就放在编程中说了：
首先，要创建四个接口，分别是，轮子，车底，车身，汽车。这四个接口里各自约定一些方法，比如说轮子的接口中，写一个带参的轮子尺寸方法。然后比如造汽车，造的是小轿车轮子的话，那么写一个实现这个接口的实现类，类名是小轿车车轮。要是现在突然又有新的需求，要造卡车轮子，那再写一个实现类来实现这个车轮的接口即可，其实这里用到了一个其他的原则（开闭原则：对修改关闭，对扩展开放），接口中的方法呢，是之前约定好的东西，是不允许修改的，这里的不允许不是指真的不允许，而是有悖于设计原则的开闭原则，一个简单又好记的方法就是：接口的存在最主要的目的就是为了便于扩展、和维护。
总之，依赖倒转原则是针对接口的，高层模块和底层模块都是依赖于抽象（接口）的。
PS：本文如果有错误的观点或者理论，真心希望各位道友给我指，让我们共同进步，谢谢。