前言
毕竟是做了两年的开发,对于设计模式的六大原则算是有点熟悉的,只是没了解的这么全面,这次咱们一次讲清楚这六大原则是啥。
开闭原则
对扩展开放,对修改关闭。(在不改变原有代码的基础上通过扩展来实现新功能)
这条设计原则是六条里最重要的!
软件的兼容性其实是很重要的东西,咱们不能轻易的把原先程序的功能做修改,这样子兼容性就很差了。想实现或者修改一个功能时,最好能通过新增模块的方式实现。
举个例子,做一个游乐场的售票功能。某天游乐场举办活动,在满足某些条件时顾客可以享受折扣优惠。
比较差劲的做法是,直接把计算票价的函数给改掉。
比较好的做法是,先做一层封装,比如搞个抽象类,这类里存放的是方法,然后用抽象类的不同子类去不同的实现计算票价的方法。如此一来,旧的计算票价的方法还在那里,只是通过扩展了新的方法,满足了需求。某天活动结束了,旧的功能还能继续用。
里式替换原则
这个原则之前鹏哥讲过,当时我还认真听了一下。即,子类必须能替换他们的父类!比如我写个函数,形参是父类对象,那么它就一定必须能接受一个子类对象,而且程序不会产生任何错误或者是异常。
这个原则其实是为了约束大家,不要瞎搞类的继承,要按照这个规则来搞继承。
我们聊几个可能违背里式替换原则的做法:
1.子类抛出了父类不可能会抛出的异常。
这就纯属坑爹了,如何处理呢?很简单,请子类自我消化掉这些异常。
2.退化函数。
退化函数就是,子类override了父类的一个函数,但是它啥也不做。
那咱们应该怎么做来避免违反里式替换原则呢?
我个人认为,子类尽量不要去override父类的非抽象方法,因为一旦你override了父类的非抽象方法,那就有点僵硬了,比如上面我说的异常,当然还有很多。如果你非要override父类方法,那就请你把父类的方法写成抽象方法,这就万事大吉了。如果你非得override父类的普通方法,那请把输入范围搞得更大,但是输出搞得更严格。(宽进严出)
依赖倒转原则
这个我之前不是很熟悉,咱们一起了解一下。
抽象不应该依赖于具体类,具体类应当依赖于抽象。
这句话其实非常好理解,讲的就是,要针对接口编程,而不是针对实现编程。
啥意思呢?其实很简单,比如函数在接受输入参数的时候,尽量不要接受一种实现类对象,而是多接受一点抽象类对象,你懂我意思吧?
另外呢,想实现这个原则,咱们就得在某些地方上约束一下自己了。比如说,子类就尽量不要搞一些抽象类没有的东西,不然咱们调用的时候还是得接受一个实现类的对象,这就很僵硬。
单一职责原则
一个类只负责一个功能领域中的相应职责。
换句话说,如果这个类需要改变,那么原因只能是一个。
兄弟,想想,如果一个类的功能太多,那么这些功能和功能之间的耦合就很紧密,这很僵硬的。而且,这个类的职责越多,这段代码被复用的可能性就降低了。(啥?你说你喜欢写代码?)
为了满足这条规则,咱们得做好职责划分,这个具体情况具体分析。
接口分离原则
使用多个专门的接口,而不使用单一的总接口,即客户端不应该依赖那些它不需要的接口。
其实就是用单一职责的思想去规范接口设计。别把所有的接口放在一起,咱们按照功能将接口做分割。
总之,对于接口,该干的事情都得干,不该干的事情别干。
知道最少原则
也叫迪米特原则。
通俗的来讲,就是一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类来说,无论逻辑多么复杂,都尽量地的将逻辑封装在类的内部,对外除了提供的public方法,不对外泄漏任何信息。迪米特法则还有一个更简单的定义:只与直接的朋友通信。首先来解释一下什么是直接的朋友:每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖、关联、组合、聚合等。其中,我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友,而出现在局部变量中的类则不是直接的朋友。也就是说,陌生的类最好不要作为局部变量的形式出现在类的内部。