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