原则一 单一职责原则
单一职责原则（SRP：Single responsibility principle）又称单一功能原则
核心：解耦和增强内聚性（高内聚，低耦合）。
原则二：里氏替换原则（LSP：Liskov Substitution Principle）
核心：在任何父类出现的地方都可以用他的子类来替代（子类应当可以替换父类并出现在父类能够出现的任何地方）
四层含义：
（1）子类必须完全实现父类的方法。在类中调用其他类是务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则。
（2）子类可以有自己的个性。子类当然可以有自己的行为和外观了，也就是方法和属性
（3）覆盖或实现父类的方法时输入参数可以被放大。即子类可以重载父类的方法，但输入参数应比父类方法中的大，这样在子类代替父类的时候，调用的仍然是父类的方法。即以 子类中方法的前置条件必须与超类中被覆盖的方法的前置条件相同或者更宽松。
（4）覆盖或实现父类的方法时输出结果可以被缩小。
原则三：依赖注入原则
依赖注入原则（DIP：Dependence Inversion Principle）
别名：依赖倒置原则或依赖反转原则
核心：要依赖于抽象，不要依赖于具体的实现
三层含义：
（1）高层模块不应该依赖低层模块，两者都应该依赖其抽象（抽象类或接口）；
（2）抽象不应该依赖细节（具体实现）；
（3）细节（具体实现）应该依赖抽象。
三种实现方式：
1、通过构造函数传递依赖对象；
2、通过setter方法传递依赖对象；
3、接口声明实现依赖对象在Java中的表现：
（1）模块间的依赖是通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；
（2）接口或抽象类不依赖于实现类；
（3）实现类依赖接口或抽象类。
原则四：接口分离原则
接口分离原则(ISP：Interface Segregation Principle) 别名接口隔离原则
核心思想：
不应该强迫客户程序依赖他们不需要使用的方法。
接口分离原则的意
思就是：一个接口不需要提供太多的行为，一个接口应该只提供一种对外的功能，不应该把所有的操作都封装到一个接口当中
接口隔离原则的定义
第一种定义:客户端不应该依赖它不需用的接口。
第二种定义：一个类对另外一个类的依赖性应当是建立在最小的接口上的。
接口分以下两种：
对象接口（Object Interface）Java中声明的一个类，通过new关键字产生的一个实例，对一个类型事物的描述，也是一种接口。
类接口（Class Interface）通过关键字Interface定义的接口。
分离接口的两种实现方法：
（1）使用委托分离接口。（Separation through Delegation）就把请求委托给别的接口的实现类来完成需要的职责，就是适配器模式(Adapter)。
（2）使用多重继承分离接口。（Separation through Multiple Inheritance。）该方法通过实现多个接口来完成需要的职责。
两种方式各有优缺点，通常我们应该先考虑后一个方案，如果涉及到类型转换时则选择前一个方案。
原则五：开闭原则
开闭原则（OCP：Open Closed Principle）
核心思想：对扩展开放，对修改关闭。即在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。
根据开闭原则，在设计一个软件系统模块（类，方法）的时候，应该可以在不修改原有的模块（修改关闭）的基础上，能扩展其功能（扩展开放）。
扩展开放：某模块的功能是可扩展的，则该模块是扩展开放的。软件系统的功能上的可扩展性要求模块是扩展开放的。
修改关闭：某模块被其他模块调用，如果该模块的源代码不允许修改，则该模块修改关闭的。软件系统的功能上的稳定性，持续性要求是修改关闭的。
开闭原则的实现方法为了满足开闭原则的对修改关闭（closed for modification）原则以及扩展开放（open for extension）原则，应该对软件系统中的不变的部分加以抽象，在面向
对象的设计中：
（1）、可以把这些不变的部分加以抽象成不变的接口，这些不变的接口可以应对未来的扩展；
（2）、接口的最小功能设计原则。根据这个原则，原有的接口要么可以应对未来的扩展；
（3）、不足的部分可以通过定义新的接口来实现；
（4）、模块之间的调用通过抽象接口进行，这样即使实现层发生变化，无需修改调用方的代码。
接口可以被复用，但接口的实现却不一定能被复用。接口是稳定的，关闭的，但接口的实现是可变的，开放的。
可以通过对接口的不同实现以及类的继承行为等为系统增加新的或改变系统原来的功能，实现软件系统的柔软扩展。
简单地说，
软件系统是否有良好的接口（抽象）设计是判断软件系统是否满足开闭原则的一种重要的判断基准。现在多把开闭原则等同于面向接口的软件设计。
开闭原则的相对性软件系统的构建是一个需要不断重构的过程，在这个过程中，模块的功能抽象，模块与模块间的关系，都不会从一开始就非常清晰明了，所以构建100%满足开
闭原则的软件系统是相当困难的，这就是开闭原则的相对性。但在设计过程中，通过对模块功能的抽象（接口定义），模块之间的关系的抽象（通过接口调用），抽象与实现的分离（面向接口的程序设计）等，可以尽量接近满足开闭原则。
原则六：迪米特法则
迪米特法则（LOD：Law of Demeter）又叫作最少知识原则（Least Knowledge Principle 简写LKP）
核心思想：一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。（类间解耦，低耦合）意思就是降低各个对象之间的耦合，提高系统的可维护性；在模块之间只通过接口来通信，而不理会模块的内部工作原理，可以使各个模块的耦合成都降到最低，促进软件的复用。
在将迪米特法则运用到系统的设计中时，应注意的几点：
①在类的划分上，应该创建有弱耦合的类；
②在类的结构设计上，每一个类都应当尽量降低成员的访问权限