开闭原则
定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
单一职责原则
定义：不要存在多于一个导致类变更的原因。一个类只负责一项职责。
比如，原有一个Animal类有eat()和drink()方法来代表动物的吃喝动作：
public class Animal {
private void eat() {
System.out.println("吃");
}
private void run() {
System.out.println("跑");
}
}
但是随着功能需求增加，发生了职责扩散，可能需要管理动物具体的吃什么，喝什么。
一种办法是修改原有的方法来实现，为两个方法都传入一个参数代表具体动物，在方法体中通过参数识别动物来产生对应的具体行为：
public class Animal {
private void eat(String animal) {
if (animal == "牛") {
System.out.println("牛吃草");
}
if (animal == "鸡")
System.out.println("鸡啄米");
}
private void run() {
if (animal=="牛" || animal =="狗") {
System.out.println("四条腿在跑");
}
if (animal=="鸡") {
System.out.println("两条腿在跑");
}
}
}
这种解决方法的问题在于每次职责扩散，都需要修改原先的方法，当这个类方法很多时，每次职责扩散意味着你都要修改这个类中的每一个方法。这样很容易由于修改原有代码，会对之前提供给调用者的功能造成影响，对原有程序正确运行有很大的风险（特别是当逻辑变得很复杂的时候，修改代码很容易出bug）。
软件实体（如类、模块和函数）应该是对扩展开放，对修改关闭（开闭原则）。模块要提供新的功能应当尽量在不修改原来代码的情况下进行扩展。例如为不同的动物定义一个继承自Animal的类，在新的类上实现动物特有的动作。
里氏替换原则
定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。
定义2：所有引用基类的地方能透明地使用其子类的对象。
类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法（子类可以扩展父类的功能，但不能改变父类原有的功能）。当重载父类的方法时，重载的方法的功能不能与父类对应方法的功能相悖。
继承作为面向对象三大特性之一，在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果被其他的类所继承需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。
依赖倒置原则
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
依赖倒置原则的核心思想是面向接口编程，程序应当依赖于抽象接口，而不依赖于具体实现，使程序不需要设计任何具体的操作实现，降低了程序与被调用模块间的耦合度。这样搭建起来的程序架构也会相对稳定（例如SpringMVC架构，在Controller那层常常依赖的是Service层的接口，而不是具体实现）。
传递依赖关系有三种方式：接口传递、构造方法传递和setter方法传递。
接口隔离原则
定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
即尽量细化接口，为各个类建立其专用的接口，不要试图建立一个庞大的接口去供所有依赖于它的类去调用。因为如果接口庞大，调用这个接口意味着，对应的实现这个接口的实现类必须实现这个接口的所有方法，即使调用这个接口的客户端用不到这么多方法。
但也不能把接口细化的太小，接口设计的太小，接口数量过多会使设计变得复杂。
遵循接口隔离原则不让接口变得臃肿可以提升系统的灵活性与可维护性。
迪米特法则
定义：一个对象应该对其他对象保持最少的了解。
即尽可能少的与其他对象发生相互作用（此相互作用非交互，不是指尽可能少的发生交互，而是对其依赖的对象的了解尽可能少）。
被依赖的类逻辑尽可能的封装在类的内部。除了对外提供public方法，不对外泄露任何信息。这样可以降低类与类之间的耦合性。耦合性越低，代码的复用率才越高。