人很懒惰,不愿意多写代码,即便是Ctrl C+Ctrl V。也不愿意把别人的代码改来改去,由此产生了各种复用的方法和设计原则。
目录
单一职责原则
一个类就做一件事。
职责划分极其清晰,不多管闲事。
里氏转换原则
用父类的指针存一个子类指针。
在传参的时候,传入一个父类指针是可以的,但传入这个类的子类指针是不可行的。
依赖倒置原则
上层模块应该依赖于下层的模块。
下层的模块不应该依赖于上层的模块。
换句话说就是下层的、基础的、贴近底层的逻辑,应该尽量处理自己内部的事情,不能依赖其他模块的内容。
迪米特原则
不要“管闲事”,做到高内聚低耦合。
但也不能完全解耦合,不然没有联系的话根本无法运行。
接口隔离原则
不应该直接让接口A去调用接口B,而是建立一个”中间人"。
举例:伤害机制。
使用接口隔离了,就是两个类在进行调用的时候啊,不需要去知道它的结构是什么样的,不需要子弹,不需要去知道牛头人,然后僵尸,或者桌椅板凳、电脑玻璃是什么样的东西,我们只需要让他去做一件事:继承伤害接口。
这样的话,我们就把一个类对另外一个类的依赖建立在最小的接口上了。
子弹是需要依赖怪物的那些特性的,让它受伤,让玻璃炸开,让电脑坏掉,要做到这一点,你就要依赖别人,但是你不能直接去拿他们,你直接拿就错了。
所以这就是依赖接口隔离的一个好处,我们借助接口去把这个行为给他隔离开了,子弹才不知道他打到的是谁,子弹只知道他打到的这个人具备这样的行为接口。
开闭原则
对修改关闭,对扩展开放。
这个开闭原则是给那些不着调的策划,不着调的PM,不着调的leader听的,
也就是说,如果他让你改你以前已经写好了的功能,稳定的功能,告诉他不要改。
我们可以加功能,我们不能改功能,为什么呢?因为你一改就可能会出现很多问题。
举个例子啊。
这个火箭飞不起来。
对吧,火箭飞不起来,外行人就说,诶,这火箭放在这里一点火呲蹿个十米20米就掉下来,外行人就说,哎呀,这简单啊,那推进器他的那个推力不够嘛,我再给他绑两个那个往上窜火,那个东西往下边窜火,那东西不就飞起来了吗?这就是外行人的理解,但是内行人肯定还在去想很多的东西,比如说你的燃料的一个配给啊,对不对,你的材料的兼顾度啊,你的平衡啊,你的质量啊,你的重量啊,对不对?很多东西都需要调整,就是这个样子。
就是很多时候一个需求看起来很简单,但是其实这个需求涉及到要修改的点和内容,对于我们来说是非常多的,这也是程序最吃亏的地方。程序其实很多时候做的都是那种吃哑巴亏,没办法你跟他讲,你说你的这个需求可能会破坏我们原有的一些设计平衡。
对,他听不懂,这也是为什么程序经常和策划干仗的原因,现在我听到最多的一句话就是策划过来提需求,程序就直接一句话,这东西不做。
我做不了。
哎,他为什么说这句话,其实最主要原因就是可能它的生产成本太高了。
组合/聚合复用原则
组合设计方案要优于继承设计方案,为什么呀?因为继承层次越深。
子类的行为属性就会越会臃肿,我们刚才已经说了,就是父类,它会强迫子类具备一些内容。我们可以把功能拆解成为独立的一个个的功能。
用的时候我们把功能放到自己的身上就可以了,而不用说我一生下来我必须要带这些东西,因为这个东西它是会会在这个继承术会一直往下传承的。