** 2019-12-03 10:25:03 ** 单一职责原则 开放封闭原则 依赖倒转原则 里氏代换原则 ...待补充
单一职责原则
就一个类而言，应该仅有一个引起它变化的原因。
例如：俄罗斯方块。 每一个键位，下降、左移、右移、旋转都只对应了一个动作(职责)。
如果一个类承担的职责过多，就等于把这些耦合在了一起，一个职责的变化可能会削弱或抑制这个类完成其他职责的能力。 这种耦合会导致脆弱的设计，当变化发生时，设计会遭受意想不到的破坏。
软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。 如果你能想到多余一个动机去改变一个类，那么这个类就具有多余一个职责。
开放封闭原则
软件实体(类，模块，函数...等等)应该是可以扩展，但是不可修改。 对于扩展是开放的，对于修改是封闭的。
例如：弹性上班工作制度。 有的公司员工离公司很远，上班还要送小孩子上学，经常迟到。身为老板，直接按照迟到制度扣钱？还是网开一面允许迟到？
- 直接扣钱：员工对工资不满意，离职想法。
- 允许迟到：其他员工对此也非常不爽，我也天天迟到。
其实，老板想要的只是每天8个小时的上班时间，甚至时间都不重要，想要的只是业绩目标能完成或者超额完成。 于是就有了弹性上班制度：
- 早上班早下班
- 允许迟到次数，迟到了当天下班后补时间
- 甚至对销售人员以业绩为准 ... 等等
开放封闭原则：对时间制度的扩展开放，对工作时间或业绩成绩的关闭。
绝对封闭是不可能的，无论模块多么‘封闭’，都会存在一些无法对之封闭的变化。 所以，设计人员必须对于他设计的模块应该对哪种变化做出选择。他必须猜测出最有可能发生的变化总类，然后构造抽象来隔离变化。
面对需求，对程序的改动是通过增加新代码进行的，而不是改现有代码。 开放封闭原则是面向对象设计的核心所在，遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。 开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。 拒绝不成熟的抽象和抽象本身一样重要。
依赖倒转原则
高层模块不应该依赖低层模块。两个都应该依赖抽象 抽象不应该依赖细节，细节应该依赖于抽象 要针对接口编程，不要对实现编程
例如：电脑零件。 无论主板、CPU、内存、硬盘都是针对接口设计的， 如果针对实现来设计，内存对应到某品牌的主板，那么换内存的时候就会有要换主板的尴尬。
依赖倒转可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程， 即程序的所有的依赖关系都终止于抽象类或者接口，那就是面向对象的设计，反之就是过程化的设计了。
里氏代换原则
子类必须能够替代掉他们的父类型 解释：一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。 也就是说，在软件里面，把父类替换成子类，程序的行为没有变化。 简单的说，子类型必须能够替换掉他们的父类型。
例如：
- 错误的：父类-鸟-飞的方法，子类-企鹅。
- 正确的：父类-动物-吃喝拉撒的方法，子类-猫狗等。
