开闭原则
依赖倒置原则
单一职责原则
接口隔离原则
迪米特法则（最少知道原则）
里氏替换原则
合成/复用原则

UML类图

#:protected
~:默认，包权限
下划线：static
斜体：抽象方法

开闭原则

类应该对扩展开放，对修改关闭。

扩展就是添加新功能的意思，因此该原则要求在添加新功能时不需要修改代码。

符合开闭原则最典型的设计模式是装饰者模式，它可以动态地将责任附加到对象上，而不用去修改类的代码。

依赖倒置原则

高层次模块不应该依赖于低层的

例如扩展的时候是面向ICourse接口的，而不是在Geely类中添加study方法，main函数也不需要调用Geely的对象的具体课程方法。

大概是：不要写很多不同名字的实现方法，而是去写很多类去继承接口，然后传不同的参数来调用不同类，这些类里的方法名字相同，但实现不同。

单一职责原则

修改一个类的原因应该只有一个。
换句话说就是让一个类只负责一件事，当这个类需要做过多事情的时候，就需要分解这个类。
如果一个类承担的职责过多，就等于把这些职责耦合在了一起，一个职责的变化可能会削弱这个类完成其它职责的能力。

接口隔离原则

不应该强迫客户依赖于它们不用的方法。
因此使用多个专门的接口比使用单一的总接口要好。

迪米特原则

对象对其他对象保持最少的了解，所以少用public
尽量降低类之间的耦合
只和朋友交流（入参出参、成员变量。。其他内部出现的类不是朋友，尽量搞出去）

里氏替换原则

子类能够替换父类。
重载时，子类的入参要比父类宽松。
返回时，子类要更严格。

合成/复用原则

黑箱复用。

下面类图中描述的例子。“人”被继承到“学生”、“经理”和“雇员”等子类。而实际上，学生”、“经理”和“雇员”分别描述一种角色，而“人”可以同时有几种不同的角色。比如，一个人既然是“经理”，就必然是“雇员”；而“人”可能同时还参加MBA课程，从而也是一个“学生”。使用继承来实现角色，则只能使每一个“人”具有Is-A角色，而且继承是静态的，这会使得一个“人”在成为“雇员”身份后，就永远为“雇员”，不能成为“学生”和“经理”，而这显然是不合理的。

这一错误的设计源自于把“角色”的等级结构和“人”的等级结构混淆起来，把“Has-A”角色误解为“Is -A”角色。因此要纠正这种错误，关键是区分“人”与“角色”的区别。下图所示的的设计就正确的做到了这一点。