依赖倒置的原则简单理解

 

业务场景（高层）：

  业务场景将代码串联到了一起，业务场景是使用者，代码是服务者。任何业务的变更都应停留在业务场景层面。而不是代码层面。依赖倒置模式就能够帮助我们在业务不断变更的前提下，减少重构已经稳定运行的代码。这样可以保证即使修改了A模块的业务场景，也不会影响已经上线稳定运行的B模块和C模块。

代码（低层）--也许名字起得不太好

程序员写的一些功能。多个代码组在一起，就变成了业务的应用场景。

 

依赖倒置就是面向接口编程：

在具体体现中，高层调用底层时不依赖具体细节（实现类），而是使用抽象调用（接口或者抽象类）：

在两个不同功能的模块之间，也通过抽象类去调用。

这属不属于依赖倒置呢？

  1、比如说在mvc中 controller 在调用service就是通过接口调用。而不是直接调用的实现类。service调用mapper 或者是Dao时，也是通过接口调用。

优点：比方说大家不管用hashMap 还是LinkedHashMap。都喜欢用Map去接收。

　　如果没有依赖倒置的话new一种map就得用一种map接收，多麻烦

 

在实际开发中：当某个类不适用某个场景时，就把那个类的方法拷出来放到场景中从新写一遍。但也可以搞个这个类的继承类，复写那个类有毛病的方法。