【设计模式】依赖倒转原则

前端之家收集整理的这篇文章主要介绍了【设计模式】依赖倒转原则前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

依赖倒转原则DIP

DependenceInversion Principle,依赖于抽象,不要依赖于具体。定义:A 、高层模块不应该依赖底层模块。两个都应该依赖抽象;B 、抽象不应该依赖细节,细节应该依赖于抽象。说白了就是针对接口,不要对实现编程。

例如主板和内存条,主板属于高层模块,内存条属于底层模块,如果主板或内存条坏了,各自换掉就OK了,而不是说主板坏了,内存条就没有了,要换都换掉。只要主板和内存条的接口能够链接上,那么就可以继续使用,它们是相互独立的,都依赖于抽象,这样降低了耦合度。

里氏替换原则LSP

Liskov Substitution Principle,面向对象设计的基本原则之一。定义:子类型必须能够替换掉它们的父类一个软件实体如果使用的是一个父类的话,那么一定使用其子类,而且它察觉不出父类对象和子类对象的区别,也就是说,在软件里面,把父类都替换成它的子类,程序的行为没有变化。

里氏替换原则使得继承复用成为可能。只有当子类可以替换掉父类,软件单位的功能不受到影响时,父类才能真正被复用,而子类也能够在父类的基础上增加新的行为。或者可以用一句话概述“老鼠的儿子会打洞”,这样或许更容易明白。

由于子类型的可替代性才使得父类型的模块在无需修改的情况下就可以扩展。


依赖倒转特点

依赖倒转其实谁也不依靠谁,除了约定的接口,大家都可以灵活自如。

依赖倒转其实可以说是面向对象设计的标志,用哪种语言来编写程序不重要,如果编写时考虑的都是如何针对抽象过程而不是针对细节编程,即程序中所有的依赖关系都是终止于抽象类或者接口,那就是面向对象设计,反之就是过程化的设计了。


过程与对象的区别

面向过程的开发,上层调用下层,上层依赖于下层,当下层剧烈变动时上层也要跟着变动,这就会导致模块的复用性降低而且大大提高了开发的成本。

面向对象的开发很好的解决了这个问题,一般情况下抽象的变化概率很小,让用户程序依赖于抽象,实现的细节也依赖于抽象。即使实现细节不断变动,只要抽象不变,客户程序就不需要变化。这大大降低了客户程序与实现细节的耦合度

猜你在找的设计模式相关文章