六大原则
一、单一职责原则(Single Responsibility Principle)
应该有且仅有一个原因引起类的变更。
问题场景：
类C负责两个不同的职责：职责D1，职责D2。当由于职责D1需求发生改变而需要修改类C时，有可能会导致原本运行正常的职责D2功能发生故障。
单一职责最难划分的就是职责，一个职责一个接口，但问题是”职责“没有一个量化的标准，一个类到底要负责哪些职责？这些职责怎么细化？细化后是否都要有一个接口或类？这些都需要从实际的项目去考虑。
解决方案：
遵循单一职责原则。分别建立两个类C1、C2，使C1完成职责D1功能，C2完成职责D2功能。这样，当修改类C1时，不会使职责D2发生故障风险；同理，当修改C2时，也不会使职责D1发生故障风险。
比如说一个用户类，应该把用户的信息抽取成一个BO（Business Object，业务对象），把行为抽取成一个Biz（Business Logic，业务逻辑）。这样前者的职责是收集和反馈用户的属性信息；后者的职责是完成用户信息的维护和变更。分成这样的两个接口来设计之后，这两个职责的变化就不会互相影响。
单一职责的好处：
- 类的复杂性降低，实现什么职责都有清晰明确的定义；
- 可读性提高；
- 可维护性提高；
- 变更引起的风险降低。
变更是必不可少的，如果接口的的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。
二、里氏替换原则(Liskov Substitution Principle)
定义一（标准定义）：如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。
定义二（通俗定义）：所有引用基类的地方必须能透明地使用其子类的对象。
从定义二中可以理解到，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本不需要知道是父类还是子类。但反之就不行了。
里氏替换原则的规范：
1. 子类必须完全实现父类的方法
在类中调用其他类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了LSP原则。
- 如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生”畸变“，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。
- 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
- 子类可以有自己的个性
- 子类中可以增加自己特有的方法。因为子类可能有比父类多的属性和行为，所以向下转型是不安全的，从LSP来看，就是有子类出现的地方父类未必就可以出现。
2. 覆盖或实现父类的方法时参数可以被放大
- LSP要求制定一个契约，就是父类或接口，这种设计方法也叫做Design by Contract。契约制定了，也就同时制定了前置条件（即方法的形参）和后置条件（即方法的返回值）。
- 在实际应用中父类一般都是抽象类，子类是实现类，子类中方法的前置条件必须与超类中被覆写的方法的前置条件相同或者更宽松。
3. 覆写或实现父类的方法时输出结构可以被缩小
- 父类的一个方法的返回值是一个类型T，子类的相同方法（重载或覆写）的返回值为S，那么LSP就要求S必须小于或等于T。
三、依赖倒置原则(Dependence Inversion Principle)
高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
问题场景：
类A直接依赖于类B，假如要将类A改为依赖于类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，类B和类C是低层模块，假如修改了类A，可能会给程序带来不必要的风险。
解决方案：
将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类或者类C发生联系，则会大大降低修改类A的几率。
依赖倒置原则的核心思想是面向接口编程。
依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。
依赖的三种写法：
依赖是可以传递的，对象的依赖关系有三种方式来传递：
- 构造函数传递依赖对象。在类中通过构造函数声明依赖对象，按照依赖注入的说法，这种方式叫作构造函数注入；
- Setter方法传递依赖对象。在抽象类中设置Setter方法声明依赖关系，依照依赖注入的说法，这是Setter依赖注入；
- 接口声明依赖对象。在接口的方法中声明依赖对象，这种方法也叫做接口注入。
最佳实践：
依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合。在实际项目中，如何应用这个规则呢，只要遵循以下几个规则就可以：
- 每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备，这是依赖倒置的基本要求，有了抽象才可能依赖倒置；
- 变量的表面类型尽量是接口或者是抽象类；
- 任何类都不应该从具体类派生；
- 尽量不要覆写基类的方法；
- 结合里氏替换原则使用：接口负责定义public属性和方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，同时在适当的时候对父类进行细化。
四、接口隔离原则(Interface Segregation Principle)
客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
接口分为两种：
- 实例接口：在Java中声明一个类，然后用new关键字产生一个实例，它是对一个类型的事物的描述，这是一种接口，从这个角度来看，Java中的类也是一种接口；
- 类接口：Java中经常使用的interface关键字定义的接口。
什么是隔离呢？它有两种定义：
- 客户端不应该依赖它不需要的接口；
- 类间的依赖关系应该建立在最小的接口上。
这两句话可以概括为一句话：建立单一接口，不要建立臃肿庞大的接口。更通俗的讲：接口尽量细化，同时接口中的方法尽量少。
问题由来：
类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。
解决方案：
将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
接口隔离原则 vs. 单一职责原则:
二者的审视角度不同，单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少，它要求“尽量使用多个专门的接口”。
最佳实践：
- 接口要尽量小，一个接口只服务于一个子模块或业务逻辑，根据接口隔离原则拆分接口时，首先必须满足单一职责原则；
- 接口要高内聚，具体来讲就是在接口中尽量少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险也就越少，同时也有利于降低成本；
- 已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理；
- 定制服务：定制服务是单独为一个个体提供优良的服务，要求是只提供访问者需要的方法；
- 接口设计是有限度的：接口设计的粒度需要根据经验和常识进行合理的判断。
五、迪米特法则(Least Knowledge Principle)
一个对象应该对其他对象有最少的了解，即一个类应该对自己需要耦合或调用的类知道得最少，只关注自己调用的public方法，其他的一概不关心。
最佳实践：
迪米特法则的核心思想就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高。其要求的结果就是产生了大量的中转或跳转类，导致系统的复杂性提高，同时也为维护带来了的难度。因此在采用迪米特法则时，既要做到让结构清晰，又做到高内聚低耦合。
开闭原则
一个软件实体类，如类、模块和函数应该对扩展开放，对修改关闭。
问题由来：
开闭原则是一个非常虚的原则，前面5个原则是对开闭原则的具体解释，但是开闭原则并不局限于这么多。在实际工作中需要注意以下几点：
- 抽象约束：抽象是对一组事物的通用描述，没有具体的实现，也就表示它可以有非常多的可能性，可以跟随需求的变化而变化。因此接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放。
- 元数据控制模块行为：元数据是用来描述环境和数据的数据，通俗地讲就是配置参数，参数可以从文件中获得，也可以从数据库中获得，使用此方法的极致就是控制反转，使用最多的就是Spring容器。
- 制定项目章程：对项目来说，约定优于配置。章程中指定了所有人员都必须遵守的约定。
- 封装变化：将相同的变化封装到一个接口或抽象类中；将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。封装变化，也就是受保护的变化，找出预计有变化或不稳定的点，为这些变化点创建稳定的接口。
六大设计原则应用
理解：
从整体上来理解六大设计原则，可以简要的概括为一句话，用抽象构建框架，用实现扩展细节，具体到每一条设计原则，则对应一条注意事项：
- 单一职责原则告诉我们实现类要职责单一；
- 里氏替换原则告诉我们不要破坏继承体系；
- 依赖倒置原则告诉我们要面向接口编程；
- 接口隔离原则告诉我们在设计接口的时候要精简单一；
- 迪米特法则告诉我们要降低耦合；
- 开闭原则是总纲，告诉我们要对扩展开放，对修改关闭。
遵守：
理解了这六大设计原则之后，如何来遵守呢？制定这六条原则的目的并不是要我们刻板的遵守，而是根据实际需要灵活运用。只要对它们的遵守程度在一个合理的范围内，就算是良好的设计，用一幅图来说明一下：
图等会再说，并且还少了一个原则