单一职责原则——优化代码的第一步
英文名称：Single Responsibility Principle，缩写SRP
定义：一个类应该仅有一个引起它变化的原因，简单的来说，一个类中应该是一组相关性很高的函数、数据的封装
单一职责所表达出的用意就是“单一”二字，如何划分一个类、一个函数的职责，每个人都有自己的看法，这需要根据个人经验、具体业务逻辑而定。但是它也有一些基本的知道原则，例如，两个完全不一样的功能就不应该放在一个类中。工程师可以不断地审视自己的代码，根据具体的业务、功能对类进行相应的拆分，这是程序员优化代码迈出的第一步。
开闭原则——让程序更稳定、更灵活
英文名称：Open Close Principle，缩写OCP
定义：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改时封闭的。
在软件的生命周期中，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会将错误引入原本已经经过测试的旧代码中，破坏原有系统。因此，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。当然现实开发中，只通过继承的方式来升级、维护原有系统只是一个理想化的愿景，因此，在实际的开发中，修改原有代码、扩展代码往往是同时存在的。
程序一旦开发完成，程序中一个类的实现只应该因错误而被修改，新的或者改变的特性应该通过新建不同的类实现，新建的类可以通过继承的方式来重用原类的代码——波兰特·梅耶1988年出版的《面向对象软件构造》
开闭原则指导我们，当软件需要变化时，应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。
当代码出现臃肿冗余的情况时，我们应该尽早的重构，而不是盲目的通过继承等方式添加新的实现，因此，在开发过程中需要结合具体情况进行考量，是通过修改旧的代码还是通过继承使得软件系统更稳定、更灵活，在保证去除“代码腐化”的同时，也保证原有模块的正确性
里氏替换原则——构建扩展性更好的系统
英文名称：Liskov Substitution Principle，缩写LSP
定义
定义一：如果对于每一个类型为S的对象O1，都有类型为T的对象O2，使得以T定义的所有程序P在所有的对象O1都替换成O2时，程序P的行为没有发生变化，那么类型S是类型T的子类型
定义二：所有引用基类的地方必须能透明地使用其子类的对象
通俗的讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是反过来就不行了，有子类出现的地方，父类未必就能适应。总而言之就是两个字：抽象
里氏替换原则的核心原理是抽象，抽象又依赖于继承这个特性，在OOP当中，继承的优缺点都相当明显
优点：
1.代码重用，减少创建类的成本，每个子类都拥有父类的方法和属性
2.子类与父类基本相似，但又与父类有所区别
3.提高代码的可扩展性
缺点：
1.继承是侵入性的，只要继承就必须拥有父类的所有属性和方法
2.可能造成子类代码冗余、灵活性降低，因为子类必须拥有父类的属性和方法
开闭原则和里氏替换原则往往是生死相依、不离不弃的，通过里氏替换来达到对扩展开放，对修改关闭的效果。
依赖倒置原则——让项目拥有变化的能力
英文名称：Dependence Inversion Principle，缩写DIP
定义：依赖倒置原则指代一种特定的解耦形式，使得高层次的模块不依赖于低层次的模块的实现细节的目的，依赖模块被颠倒了
1.高层模块不应该依赖底层模块，两者都应有依赖其对象
2.抽象不应该依赖细节
3.细节应该依赖抽象
在Java语言中，抽象指的是接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是，可以直接被实例化。高层模块就是调用端，底层模块就是具体实现类。
依赖倒置原则在Java语言中的表现就是：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，起依赖关系是通过接口或抽象类产生的。简单的来说就是面向接口编程，面向抽象编程。
接口隔离原则——系统有更高的灵活性
英文名称：Interface Segregation Principles，缩写ISP
定义：客户端不应该依赖他不需要的接口，另一种定义是：类间的依赖关系应该建立在最小的接口上。
接口隔离原则将非常庞大、臃肿的接口拆分成更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。接口隔离原则的目的是系统解开耦合，从而容易重构、更改和重新部署。
迪米特原则——更好的可扩展性
英文名称：Law of Demeter，缩写LOD，也称为最少知识原则（Least Knowledge Principle）
定义：一个对象应该对其他对象有最少的了解。
通俗的讲，一个类应该对自己需要耦合或调用的类知道的最少，类的内部如何实现与调用者或者依赖者没有关系，调用者或者依赖者只需要知道它需要的方法即可，其他的可一概不用管。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
总结
在应用开发过程中，最难的不是完成应用的开发工作，而是在后续的升级、维护过程中让应用系统能够拥抱变化。拥抱变化也就意味着在满足需求且不破坏系统稳定性的前提下保持高可扩展性、高内聚、低耦合，在经历了个版本的变更之后依然保持清晰、灵活、稳定的系统架构。