编写代码，在工作了一段时间后，在不断的面对需求变化更改，堆砌代码之后。为了之后的代码编写效率，设计和旧代码的优化设计，我们需要考虑优化和设计代码需要考虑的几大原则，以指导我们的开发和优化工作。
有经验的工程师可能记得程序员常说的SOLID原则，或者曾经学习时听过，日复一日工作加班，又不记得之前曾经学习过的理论知识，这里总结学习下，希望对看过这篇文章的人有所帮助。
单一职责原则（Single Responsibility Principle, 缩写SRP）
单一职责原则，定义为：对一个类，应该仅有一个引起它变化的原因。简言之，一个类应该是一组相关性很高的函数、数据的封装。两个完全不一样的功能就不应该放在一个类中。
开闭原则（Open Close Principle, 缩写OCP）
开闭原则是Java世界最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。
其定义是：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是对于修改是封闭的。
在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，，可能会将错误引入原本已经测试过的旧代码中，破坏原有的系统。因此当软件需要变化时，尽量通过扩展的方式来实现变化，而不是通过修改已有的代码实现。
程序一旦开发完成，程序中的一个类的实现只应该因错误而被修改，新的或者改变的特性应该通过新建不同的类实现，新建的类可以通过继承的方式来重用原类的代码。
里氏替换原则（Liskov Substitution Principle,缩写LSP）
定义一：如果对每一个类型为S的对象O1，都有类型为T的对象O2，使得以T定义的所有程序P在所有的对象O1都代换成O2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。
定义二：所有引用基类的地方必须能透明地使用其子类的对象。
里氏替换原则依赖于继承、多态特性。通俗的讲：只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者根本不需要知道是父类还是子类。但是反过来就不行，有子类出现的地方，父类未必就能适应。 总结为：抽象。
里氏替换原则的核心原理是抽象，抽象又依赖于继承这个特性。（extends)
继承的优点：
- 代码重用，减少创建类的成本，每个子类都拥有父类的方法和属性；
- 子类与父类基本相似，但又与父类有所区别；
- 提到代码的可扩展性。
继承的缺点：
-
继承是侵入性的，只要继承就必须拥有父类的所有属性和方法；
-
可能造成子类代码冗余、灵活性降低，因为子类必须拥有父类的属性和方法。
建立抽象，通过抽象建立规范，具体的实现在运行时替换掉抽象，保证系统的扩展性、灵活性。开闭原则和里氏替换原则往往是生死相依、不离不弃的。
依赖倒置原则（Dependence Inversion Principle,缩写DIP）
依赖倒置原则指代了一种特定的解耦形式，使得高层次的模块不依赖于低层次模块的实现细节的目的，依赖模块被颠倒了。
关键点：
高层模块不应该依赖低层模块，两者都应该依赖其抽象；
抽象不应该依赖细节；
细节应该依赖抽象。
Java中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点是可以直接被序列化，也就是可以加上一个关键字New 产生一个对象。 高层模块就是调用端，低层模块就是具体实现类。
依赖倒置原则在Java中的表现就是：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。 概括为：面向接口编程，或者说是面向抽象编程，这里的抽象指的是接口或者抽象类。面向接口编程是面向对象的精髓之一，就是抽象。
接口隔离原则（InterfaceSegregation Principle,缩写是ISP）
定义一：客户端不应该依赖它不需要的接口。
定义二：类间的依赖关系应该建立在最小的接口上。
接口隔离原则将非常庞大、臃肿的接口拆分成更小的和更具体的接口，这样客户将只需要知道他们感兴趣的方法。接口隔离原则的目的是系统解开耦合，从而容易重构、更改和重新部署。让客户端依赖的接口尽可能的小。即最小化依赖。
Bob大叔（Robert C Martin)在21世纪早期将单一职责、开闭原则、历史替换、接口隔离以及依赖导致（依赖反转）5个原则定义为SOLID原则，作为面向对象编程的5个基本原则。当这些原则一起应用时，它们使得一个软件系统更清晰、简单，最大程度的拥抱变化。
关键词：抽象、单一职责、最小化。
迪米特原则（Law of Demeter, 缩写是LOD）
也称最少知识（Least Knowleage Principle）原则.
一个对象应该对其他对象有最少的了解。通俗的讲，一个类应该对自己需要耦合或调用的类知道的最少，类的内部如何实现与调用者或者依赖者没关系，调用者或者依赖者只需要知道它需要的方法即可，其他的可一概不用管。类与类之间的关系越密切，耦合度越大，当一个类发生改变是，对另一个类的影响也越大。
Only talk to your immediate friends,只与直接的朋友通信。
参考资料：
《Android 源码设计模式解析与实战》
