●开闭原则

对扩展开放，对修改关闭，在代码层面而言就是在你有新的需求的时候，你应当增加新的对象来实现，而不是修改原来的对象

继承

●里氏替换原则

基类可以出现，那么子类一定也能行

• 子类必须实现父类的抽象方法，但不得重写（覆盖）父类的非抽象（已实现）方法

• 子类中可以增加自己特有的方法

• 当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松

• 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格

接口隔离原则

用多个专门的接口比使用单一的总接口要好。一个类对另外一个类的依赖性应当是建立在最小的接口上的;

一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。

举个栗子：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。

解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系

●依赖倒转原则

针对接口编程

高层模块不应该依赖低层模块，两者都应该依赖其抽象，抽象不应该依赖细节，细节应该依赖抽象

也就是说，尽量依赖接口，不要依赖细节

例如：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

●迪米特法则，最少知道原则

减少耦合

又叫做最少知道原则，就是说一个对象应当对其它对象有尽可能少的了解，类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大，所以一个对象应该对其他对象保持最少的了解，也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息，迪米特法则初衷在于降低类之间的耦合。由于每个类尽量减少对其它类的依赖，因此。很容易使得系统的功能模块独立，相互之间不存在(或很少代码体现有)依赖关系。

举个栗子：Leader想从Teacher那里知道现有Student的的总数，它们之间的调用关系应该为Leader—>Teacher—>Student，Leader与Student并无直接联系，所以在Leader类的方法中不应该出现Student类

●合成复用原则

尽量合成或者聚合而不是继承