经过一段时间对大话设计模式的学习,发现其中有几个特别基础的原则,对于这些原则我们必须有个清楚的认知,才能更好的向下进行我们的学习内容。其中依赖倒转原则在后面的一些设计模式中都有涉及,所以感觉很有必要进行学习。
前提:
电脑坏了,很简单的通过电话交流,拆下一个内存条,电脑就这样简单的被修好了,这样是不是也太简单了。。原因在哪?大家都拆过电脑,在PC端都采用的是易插拔的方式,不管哪一个坏了,仅仅更换或修改那一个就可以了。这个就是面向对象中高内聚,低耦合。CPU大家都在用,却只有那么几个公司在生产,内聚很强,独自为产品。CUP和显卡,内存条之间的联系很微弱。不存在其中一个损坏,所有东西都不能使用的现象。它们都是针对接口设计,而不是针对品牌设计。说白了就是无论是哪个公司生产的,只要接口一样,大家都可以使用。
何为依赖倒转原则?
A、一直在强调高层模块不应该依赖低层模块。两个都应该依赖抽象。
B、抽象不应该依赖细节。细节应该依赖抽象。
一直在强调抽象不应该依赖细节,细节应该依赖抽象。这是什么意思?面对对象的程序设计中三大基本特征:封装,继承,多态。个人感觉现在所说的依赖倒转原则就类似于封装。不是去面对过程实现编程功能,而是针对接口编程。细节应该依赖抽象:提前提供一个接口,需要实现具体的功能,就去封装一个功能,然后去实现这个接口。抽象依赖细节这个意思就是先做一个功能,然后在去做一个接口实现,现在做的弊端没有统一的定义,做一个功能,就需要有一个接口去实现。而第一种则是先制定一个规范,然后大家再去针对规范,做事情,去符合规范要求,在实现具体的功能。上述内容都在讲述何为依赖。那为什么要叫倒转?在PC存在这样的问题,CUP,内存条等都需要依赖主板,但是主板坏了,其他的部件都不能用了。这个也不符合我们需求啊,不能因为一个损坏,造成全体瘫痪啊。我们的目的是为更好的复用。其实主板和CUP等内容都是模块,只不过一个是低层模块,一个是高层模块。所以两者之前不应该是依赖关系,而是它们需要依赖抽象。
到现在就涉及到一个新的原则——里氏代换原则。
里氏代换原则
子类型必须能够替换掉它们的父类型。在软件里面,把父类都替换成它的子类,程序的行为没有变化。
就用书中的例子在编程的世界里,就不能用企鹅来代替鸟类。
只有当子类可以替换掉父类,软件不受到影响的时候才能真正被复用,而子类也能够在父类的基础上增加新的行为。例如动物类,都拥有吃,跑等行为,所以当我们需要狗,猫,类似行为是,继承于动物时,只需要实例,程序其他处不需要改变。
【总结】
之前没有好好看看这些基本的原则,以至于后面再学习别的模式的时候,感觉到有些费劲。一步一步走踏实还是很重要的。这个依赖倒转原则其实也没什么,好好研究一下,就行了。细节依赖抽象,实现最大程度的复用。