1.前言

设计模式中的6大基本原则是为了让我们在应用开发中能够拥抱变化，也就意味着在后续升级、维护过程中不破坏系统稳定性并保持高可扩展性、高内聚、低耦合，让项目经历多个版本后依然保持清晰、灵活、稳定的系统结构。

2.六大原则

优化代码第一步：单一责任原则
让程序更稳定更灵活：开闭原则
构建扩展性更好的系统：里氏替换原则
让项目拥有变化的能力：依赖倒置原则
系统有更高的灵活性：接口隔离原则
更好地扩展性：迪米特原则

3.详情

3.1 单一责任原则

一个类而言，应该仅有一个引起它变化的原因。简单来说，一个类中应该是一组相关性很高的函数、数据的封装。
比如当要做一个图片加载器的时候，不应该把所有的东西都写在一个类中，应该各个功能独立出来，可以分成图片加载功能和缓存功能等模块，这样类中的代码逻辑清晰可读性、可扩展性和可维护性会大大提高。

3.2 开闭原则

软件中的对象（类、模块、函数等）应该对于扩展是开放的，对于修改是封闭的。在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会讲错误引入原本已经经过测试的旧代码中，破坏原有系统。因此，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。

3.3 里式替换原则

所有引用基类的地方必须能透明地使用其子类对象。面向对象的语言三大特点是：继承、封装、多态，里式替换原则就是依赖于继承、多态这个两大特点。简单说就是只要父类出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，或者可能根本就不需要知道父类还是子类。但是反过来就不行了，有子类出现的地方，父类未必就能适应。

3.4 依赖倒置原则

其指出了一种特别的解耦形式，使得高层次的模块不依赖于低层次的模块的实现细节的目的，依赖模块被颠倒了。
几个关键点：
（1）高层模块不应该依赖底层模块，两者都应该依赖其抽象。
（2）抽象不依赖于细节。
（3）细节应该依赖抽象。

3.5 接口隔离原则

定义：客户端不应该依赖它不需要的接口。另一种定义是：类之间的依赖关系应该建立在最小的接口上。接口隔离原则将非常庞大、臃肿的接口拆分成更小和更具体的接口，这样客户端将会只需知道他们感兴趣的方法。接口隔离原则的目的是系统解开耦合，从而容易重构、更改和重新部署。

3.6 迪米特原则（最小知识原则）

一个对象应该对其他对象有最少的了解。通俗的讲，一个类应该对自己需要耦合或调用的类知道得最小，类的内部如何实现与调用者或者依赖者没关系，调用者或者依赖者只需要知道它需要的方法即可，其他的可一概不管。类与类之间关系越密切，耦合越大，当一个类方法改变时，对另一个类的影响也越大。