目录
学习说明
没有目的的学习都是耍流氓，为了证明咱不是在耍流氓，对为什么要学习设计模式做下简单说明。一个好的系统离不开设计，好的设计可以让我们快速响应满足变化的需求，一段好的代码也离不开好的代码设计，好的设计能让我们欣赏它，容易理解它，并且易拓展，易维护。所以学习设计模式可以让我们从只会ctrl+c，ctrl+v走出，多带上自己的一些思考，让自己的系统以及代码设计的更加有灵魂，有水平。
如何学习
以《设计模式之禅》（第2版）这本书为基础，辅助网上的设计模式资料，以博客输出的方式来逐渐掌握它。有一个设计模式的学习秘诀，学习它，模仿熟练使用它，然后忘掉它，当我们忘掉它之后，能够根据实际的场景应用它，那么就代表我们成一定火候了，所以蹦着这个目标努力吧。
设计模式是什么？
设计模式是什么？
它是一套理论，由软件界的先辈们总结出的一套可以反复使用的经验，它可以提高代码的可重用性，增强系统的可维护性，以及解决一系列的复杂问题。做软件的人都知道需求是最难把握的，我们可以分析现有的需求，预测可能发生的变更，拥抱即将发生的变化。设计模式给了我们指导，专家们首先提出了6大设计原则，但这6大设计原则仅仅是一系列“口号”，真正付诸实施还需要有详尽的指导方法，于是23种设计模式出现了。
设计模式不是工具，它是软件开发的哲学，它能指导你如何去设计一个优秀的架构、编写一段健壮的代码、解决一个复杂的需求。
它是指导思想，你可以在此基础上自由发挥，甚至是自己设计出一套设计模式。
总之通晓了这23种设计模式可以让我们站在一个更高的层次去赏析程序代码、软件设计、架构，完成从代码工人到架构师的蜕变。
6大设计原则
《设计模式之禅》这本书将整书分为两大部分，第一部分讲述6大设计原则，也就是前文说的“口号”，第二部分讲述23种设计模式，此篇博客我们先对6大设计原则做下简单了解。
那么6大设计原则是哪6个呢？
- Single Responsibility Principle：单一职责原则
- Open Closed Principle：开闭原则
- Liskov Substitution Principle：里氏替换原则
- Law of Demeter：迪米特法则
- Interface Segregation Principle：接口隔离原则
- Dependence Inversion Principle：依赖倒置原则
单单看上述的名字，其实是很难理解到底是啥意思的。先讲下我看完的感受，感觉确实是在喊“口号”，没有太多的实际的意义，每个原则讲的太范，无法比较好的指导我们怎么去使用它，但对于有一定开发经验的小伙伴，不妨对它有个了解。而且可能也有助于后面23中设计模式的学习。
单一职责原则
单一职责原则简单来说就是要将一个接口尽量设计的职责单一，比如我们可以设计一个电话的接口，该接口包含了打电话，挂电话，聊天，从职责划分上来说可以再进一步将打电话和挂电话定义为协议管理，聊天定义为数据的传送，所以站在单一设计原则角度可以对这个接口再根据职责进行细拆。是不是要拆，要根据需求以及实际场景进行分析，这里只介绍基本概念哈。
开闭原则
开闭原则简单来说就是已经设计写好的类，我们抱有的态度不应该是去修改它，而是去拓展它，这样子能够最大影响已投产的功能的变动，减少风险，提高代码的复用性，提高可维护性。如书中提到的书的例子，正常情况下满足卖书的设计，我们只需要设计一个书的接口，然后获取它的价格，书名，作者出售即可。但如果商店做活动，书的价格进行打九折，那么就需要我们有拓展的口子存在，让我们在不影响之前代码的基础上，能够正常的进行打九折出售。
例子如图，通过增加一个打折的对象类覆写价格这个方法，就达到不影响之前的对象又满足了降价的处理。
里氏替换原则
里氏替换原则简单来说就是java的继承这个特性，子类继承父类后拥有父类的所有的属性以及方法，使用到父类的地方可以全部用子类进行替换，不受影响。
迪米特法则
迪米特法则（Law of Demeter，LoD）也称为最少知识原则（Least Knowledge Principle，LKP），虽然名字不同，但描述的是同一个规则：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。
用以上两幅图做下说明，第一幅图teacher和groupLeader两个类都依赖了girl类，增加了三个对象间的复杂关系，而第二副图teacher依赖groupLeader，然后groupLeader又依赖girl减少了之间的关系依赖，简单明了，这也就是迪米特法则说的对象间的依赖关系能封装就封装，让关系变简单些。
接口隔离原则
接口隔离原则似乎和单一职责原则有点类似，简单来说就是建立单一接口，不要建立臃肿庞大的接口。
如以上两幅图，第一幅图的美丽女孩需要满足三个条件，第二幅图将三个条件细拆成了两个接口，满足气质好就是美丽女孩，好看，身材好也是美丽女孩，那么这就是接口隔离原则。ok，看这到还是那句话，这只是一个原则的说明，仅此而已，对于接口是否拆分，拆分到什么程度，需要从实际场景出发，如：实际场景中就是有1、2、3、4种的可能性，那么为了满足不同场景，就需要将接口设计灵活些。
依赖倒置原则
依赖倒置原则（Dependence Inversion Principle,DIP）这个名字看着有点别扭，“依赖”还“倒置”，这到底是什么意思？
- 高层模块不应该依赖低层模块，两者都应该依赖其抽象
- 抽象不应该依赖细节
- 细节应该依赖抽象
还是很抽象，非人类语言。依赖倒置原则在Java语言中的表现就是：
- 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的
- 接口或抽象类不依赖于实现类
- 实现类依赖接口或抽象类。
更加精简的定义就是“面向接口编程”——OOD（Object-Oriented Design，面向对象设计）的精髓之一。
还是用两幅图来做下简要说明，第一幅图实现的是司机直接开奔驰，driver这个方法就直接依赖了实现类了。而第二幅图driver这个方法是一个ICar接口，而这个接口有具体的奔驰，宝马等实现类，那么司机既可以开宝马也可以开奔驰，只要在driver方法中传对应的实现类进去即可。套用上面的依赖倒置原则在Java语言中的三个规则进行了解，也就不难理解了。
总结
对《设计模式之禅》的6大设计原则做了初步的了解，需要明白的是6大原则只是一个说明，一个“口号”，具体系统或者项目中的设计，需要具体分析。