软件设计原则（转）

原文：https://mp.weixin.qq.com/s?__biz=MzA3NjU5ODU1Nw==&mid=2247484119&idx=1&sn=a05e38fc0f67e9de93cd44fe2647a6bb&chksm=9f5f9ea5a82817b373c45f39fc87706f29b64eb1f8db40a688a6726c49ffe07804269e73824a&scene=27

自己的理解：

开闭原则

对类或函数，尽量用扩展代替修改，如果要增加新的功能，或者在原来的基础上有一些修改，那么尽量扩展一个新的版本，比如用继承或函数重载，尽量不要修改原有的对象，这样就不会影响用户代码

依赖倒置原则

高层模块不应该依赖底层模块细节。

文章中CarSystem的设计，高层的CarSystem类就依赖了具体的汽车类，导致每个汽车类改动的时候或者新增汽车类的时候CarSystem也必须要修改。我认为可以有2个解决方法：

1. 使用类模板来设计CarSystem类；

2. CarSystem类里可以用一个car的父类指针来保存具体的car，这个car可以是Honda也可以是Ford，它们要继承自同一父类（文中的ICar接口其实就类似于一个抽象基类，Honda和Ford都必须实现规定的接口）

单一职责原则

这个没什么好讲的，就是每个类或者函数只实现一个单一功能，尽量把每个功能拆分成小的函数

接口隔离原则

尽量使用多个专门的接口，而不使用单一的总接口。就是说不要把所有的接口都放到同一个基类里面。因为有些接口对某些继承类而言根本用不到，可以把多个接口划分到多个基类里面，这样继承来再根据自己的需要来选择继承哪些基类。

迪米特法则

一个对象应该对其他对象保持最少的了解，又叫最少知道原则（Least Knowledge Principle，LKP），尽量降低类与类之间的耦合。

其实可以解释为一个对象不要过度依赖另一个对象的特征，尽量减少类之间的耦合。

里氏替换原则

如果对每一个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序p在所有的对象o1都替换成o2时，程序p的行为没有发生变化，那么类型T2是类型T1的子类型。

可以理解为一个软件实体如果适用一个父类的话，那一定适用于其子类，所以引用父类的地方必须能透明地使用其子类的对象，子类的对象能够替换父类的对象，而程序逻辑不变。

引申含义：对类来说，子类可以扩展父类的功能，但不能改变父类原有的功能。对软件实体来说，这个程序逻辑不能依赖于继承体系里面某个类的特征，而用其他继承类替换时这个逻辑就行不通。

对类的要求：

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法
子类中可以增加自己特有的方法
当子类的方法重载父类的方法时，方法的前置条件（即方法的入参）要比父类方法的入参更宽松
当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的返回值）要比父类更严格或相等