依赖倒置的原则简单理解
业务场景(高层):
业务场景将代码串联到了一起,业务场景是使用者,代码是服务者。任何业务的变更都应停留在业务场景层面。而不是代码层面。依赖倒置模式就能够帮助我们在业务不断变更的前提下,减少重构已经稳定运行的代码。这样可以保证即使修改了A模块的业务场景,也不会影响已经上线稳定运行的B模块和C模块。
代码(低层)--也许名字起得不太好
程序员写的一些功能。多个代码组在一起,就变成了业务的应用场景。
依赖倒置就是面向接口编程:
在具体体现中,高层调用底层时不依赖具体细节(实现类),而是使用抽象调用(接口或者抽象类):
在两个不同功能的模块之间,也通过抽象类去调用。
这属不属于依赖倒置呢?
1、比如说在mvc中 controller 在调用service就是通过接口调用。而不是直接调用的实现类。service调用mapper 或者是Dao时,也是通过接口调用。
优点:比方说大家不管用hashMap 还是LinkedHashMap。都喜欢用Map去接收。
如果没有依赖倒置的话new一种map就得用一种map接收,多麻烦
在实际开发中:当某个类不适用某个场景时,就把那个类的方法拷出来放到场景中从新写一遍。但也可以搞个这个类的继承类,复写那个类有毛病的方法。
欢迎留言互动