在所有的设计模式开篇中，总是说一个好的架构，或多或少都会有设计模式的出现。当然或多或少也会使用设计模式的相关原则：
SOLID+迪米尔原则
1.优化代码的第一步：单一职责原则
S:单一职责链原则：英文名称为Single Responsibility Principle（SRP）
定义：就一个类而言，应该仅有一个引起它变化的原因。通俗来说：一个类中应该有一组相关性很高的函数、数据的封装。但是在设计模式之禅中说这个说法的争议比较大，因为单一职责的划分界限并不是那么清晰的。就像明明知道数据库设计的时候要保持一条记录的原子性，但是为了方便后期操作的时候，不需要进行表连接而快速的获取到数据，会出现部分冗余的字段。
2.让程序更稳定、更灵活的：开闭原则
O:开闭原则：英文名称为：Open Close Principle（OCP），它是Java里面最基础的设计原则：
定义：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是对于修改是封闭的。
软件开发中最让人烦恼的不是产品设计出来的功能不能实现，而是实现出来之后，下个版本要对本功能进行修改。但是如果我们修改原先的代码不能保证原先软件模块的正确性。如果我们开发的是第三方的Jar包，已经将jar给其它客户了，下个版本更新的时候要让用户所有用到jar文件的地方都要修改这很明显是十分不合理的，此时开闭原则显得非常重要。
3.构建扩展性更好的系统：里氏替换原则
L:里氏替换原则：英文名称为：Liskov Substitution Principle（LSP）
定义：所有引用基类的地方必须能透明的使用子类的对象。
面向对象三大特点：封装、继承、多态。李氏替换原则依赖于继承与多态。通俗的讲：只要父类能出现的地方，其子类一定可以出现，而且替换成子类也不会产生任何异常和错误，调用者根本就不需要知道当前调用的对象是子类还是父类。反之则不一定成立，有子类出现的地方，父类未必能适应。总结两个字就是：抽象。
里氏替换原则的核心就是抽象，抽象又依赖于继承这个特性。在OOP编程中：继承的优缺点相当明显：
优点：
1）代码重用，减少创建类的成本，每个子类都拥有父类的属性和方法
2）子类和父类基本相似，但是又比父类多了自己的特征
3）提高代码的可扩展性
继承的缺点：
从侧面上看，继承的优点基本上也就是它的缺点：
1）继承是侵入式的，只要继承就必须拥有父类的所有属性和方法。（连拒绝接收遗产的资格都没有）
2）因为子类继承了父类属性和方法，可能导致子类代码冗余。
开闭原则和里氏替换原则是相互依靠的，通过里氏替换来达到对扩展开放，对修改关闭的效果。
4.系统有更高的灵活性：接口隔离原则
I：接口隔离：InterfaceSegregation Principle（ISP）
定义：类间的依赖关系应该建立在最小的接口上。通俗的讲：让客户端依赖的接口尽可能的小
5.让项目拥有变化的功能：依赖倒置原则
D:依赖倒置：Dependence Inversion Principle（DIP）重点在解耦上面
定义：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口和抽象类产生的。
更好的扩展性：迪米特原则
6.迪米特原则：Law of Demeter（LOD）
定义：一个对象应该对其它对象有最少的了解。通俗的说，一个类对自己需要耦合或者调用的类知道的最少，类的内部如何实现与调用者或者依赖者没有关系，调用者或者依赖者只需要知道它需要的方法即可，其它的一概不用管。类与类之间的关系越密切，耦合度越大，当一个类放生改变的时候，对另一个类影响也越大。
