在应用开发的过程中，感觉最快乐也是最痛苦的莫过于优化、重构代码。在版本不断地迭代更新上线中，我们不但要保证功能能正常运行，而且我们的代码需要保证健壮性、稳定性、拓展性。然而在我们不断接受新的知识过程中，我们对代码的理解也会越来越深刻，从而出现了优化，甚至是重构代码的过程。在此之前我们更需要知道面向对象编程的五大原则。
单一职责原则（Single Responsibility Principle）
单一职责原则比较容易理解，所谓单一职责，就是对于一个类来说，应该只专注于做一件事和只有一个引起他变的原因。所谓职责，我们可以理解成功能的意思。
- 如果一个类负责的职责过多，应该细分给其他类。
- 要尽量清楚职责的划分，设计类的功能只负责它所应该负责的一个功能。
- 然而每个人对划分的理解都不一致。例一个复杂的功能封装一个类中导致代码X百行，正确是有一个个封装类来组成来实现这个功能。
开闭原则（Open Close Principle）
一个软件实体类，模块和函数应该对扩展是开放,对修改是封闭的。
在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展.换言之,应当可以在不必修改源代码的情况下改变这个模块的行为，在保持系统一定稳定性的基础上，对系统进行扩展。这是面向对象设计（OOD）的基石，也是最重要的原则。之前我们说的工厂模式就很好解析了开闭原则。
里氏替换原则（Liskov Substitution Principle）
说明：子类型必须能够替换他们的基类型。
可以很容易的实现同一父类下各个子类的互换，而替换成子类也不会产生任何错误或异常。
换个方式说就是：如果每一个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都代换称o2时,程序P的行为没有变化,那么类型T2是类型T1的子类型。
里氏替换原则核心原理是抽象，抽象又依赖于继承这个特性，继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。
我们用例子分析下：
public class JavaDemo {
public static void main(String[] args) {
A a = new A();
System.out.println("100-50=" + a.func1(100, 50));
System.out.println("100-80=" + a.func1(100, 80));
}
}
class A {
public int func1(int a, int b) {
return a - b;
}
}运行结果：
100-50=50
100-80=20新需求，我们需要增加一个新的功能：完成两数相加，然后再与100求和，由类B来负责。即类B需要完成两个功能：
public class JavaDemo {
public static void main(String[] args) {
B b = new B();
System.out.println("100-50=" + b.func1(100, 50));
System.out.println("100-80=" + b.func1(100, 80));
System.out.println("100+20+100=" + b.func2(100, 20));
}
}
class A {
public int func1(int a, int b) {
return a - b;
}
}
class B extends A {
public int func1(int a, int b) {
return a + b;
}
public int func2(int a, int b) {
return func1(a, b) + 100;
}
}类B完成后，运行结果：
100-50=150
100-80=180
100+20+100=220我们发现原本运行正常的相减功能发生了错误。原因就是类B在给方法起名时无意中重写了父类的方法，造成所有运行相减功能的代码全部调用了类B重写后的方法，造成原本运行正常的功能出现了错误。在本例中，引用基类A完成的功能，换成子类B之后，发生了异常。在实际编程中，我们常常会通过重写父类的方法来完成新的功能，这样写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的几率非常大。如果非要重写父类的方法，比较通用的做法是：原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合，组合等关系代替。
里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。它包含以下4层含义：
- 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
- 子类中可以增加自己特有的方法。
- 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
- 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
依赖倒置原则（Dependence Inversion Principle)
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
我们用例子好好理解下：
public class JavaDemo {
public static void main(String[] args) {
Mother mother = new Mother();
mother.narrate(new Book());
}
}
class Book {
public String getContent() {
return "很久很久以前有一个白雪公主";
}
}
class Mother {
public void narrate(Book book) {
System.out.println("妈妈开始讲故事");
System.out.println(book.getContent());
}
}
运行结果：
妈妈开始讲故事
很久很久以前有一个白雪公主感觉挺不错的，但是某一天需求变了，妈妈说的不是故事书，而是一份当天的报纸。报纸的代码：
class NewsPaper{
public String getContent(){
return "双12准备开启，某某大减价！";
}
} 但是妈妈没有读报纸的方法，这样妈妈就不会读报纸了，这可说不过去，那只能重载妈妈的narrate()方法。那以后读杂志、读邮件等等呢。我们需要不断修改妈妈这个高层类吗？这肯定不是一个好方法。
所以我们引入一个抽象的接口IReader。读物接口。
interface IReader{
public String getContent();
} Mother类与接口IReader发生依赖关系，而Book和NewsPaper都属于读物的范畴，他们各自都去实现IReader接口，这样就符合依赖倒置原则了，代码修改为：
public class JavaDemo {
public static void main(String[] args) {
Mother mother = new Mother();
mother.narrate(new Book());
mother.narrate(new NewsPaper());
}
}
class NewsPaper implements IReader {
public String getContent() {
return "双12准备开启，某某大减价！";
}
}
class Book implements IReader {
public String getContent() {
return "很久很久以前有一个白雪公主";
}
}
class Mother{
public void narrate(IReader reader){
System.out.println("妈妈开始讲故事");
System.out.println(reader.getContent());
}
}
interface IReader {
public String getContent();
}运行结果：
妈妈开始讲故事
很久很久以前有一个白雪公主
妈妈开始讲故事
双12准备开启，某某大减价！这样修改后，无论以后怎样扩展Main类，都不需要再修改Mother类了。这只是一个简单的例子，实际情况中，代表高层模块的Mother类将负责完成主要的业务逻辑，一旦需要对它进行修改，引入错误的风险极大。所以遵循依赖倒置原则可以降低类之间的耦合性，提高系统的稳定性，降低修改程序造成的风险。
依赖倒置原则的核心思想是：面向接口编程。
接口隔离原则 （Interface Segregation Principle）
- 一个类对另外一个类的依赖是建立在最小的接口上。
- 使用多个专门的接口比使用单一的总接口要好。
- 客户端不应该依赖它不需要的接口。
广义的接口：一个接口相当于剧本中的一种角色，而此角色在一个舞台上由哪一个演员来演则相当于接口的实现。因此一个接口应当简单的代表一个角色，而不是一个多重身份角色。如果系统设计多个角色的话，则应当每一个角色都由一个特定的接口代表。
狭义的接口（Interface）:接口隔离原则讲的就是同一个角色提供宽、窄不同的接口，以对付不同的客户端。
我们用例子理解一下：
public class JavaDemo {
public static void main(String[] args) {
A a = new A();
a.depend1(new B());
a.depend2(new B());
}
}
interface I {
public void method1();
public void method2();
public void method3();
public void method4();
}
class A {
public void depend1(I i) {
i.method1();
}
public void depend2(I i) {
i.method2();
}
}
class B implements I {
public void method1() {
System.out.println("类B实现接口I的方法1");
}
public void method2() {
System.out.println("类B实现接口I的方法2");
}
public void method3() {
System.out.println("类B实现接口I的方法3");
}
// 对于类B来说，method4不是必需的，但是由于接口I中有这个方法，
// 所以在实现过程中即使这个方法的方法体为空，也要将这个没有作用的方法进行实现。
public void method4() {
}
}运行结果：
类B实现接口I的方法1
类B实现接口I的方法2可以看到，如果接口过于臃肿，只要接口中出现的方法，不管对依赖于它的类有没有用处，实现类中都必须去实现这些方法，这显然不是好的设计。如果将这个设计修改为符合接口隔离原则，就必须对接口I进行拆分。具体如下：
interface I1 {
public void method1();
}
interface I2 {
public void method2();
public void method3();
}
interface I3 {
public void method4();
}
class A {
public void depend1(I1 i) {
i.method1();
}
public void depend2(I2 i) {
i.method2();
}
public void depend3(I2 i) {
i.method3();
}
}
class B implements I1, I2 {
public void method1() {
System.out.println("类B实现接口I1的方法1");
}
public void method2() {
System.out.println("类B实现接口I2的方法2");
}
public void method3() {
System.out.println("类B实现接口I2的方法3");
}
}接口隔离原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
在程序设计中，依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。