前言
设计模式这部分我选择的书籍是一本叫做《设计模式之禅》的书，虽然内容可能不是特别友好，但是内容详尽有层次，一眼看去就可以大致了解整个结构。对于一门学问，有时候先从整体弄懂学习内容也是一个不错的方法。
下面是书的目录，就一起来了解下吧：
第一部分：
第二部分：
第三部分：
这本书从原则开始讲起，慢慢到具体的23种设计模式，在具切到场景运用，对比。然后还有不同设计模式的组合等。
鉴于本人也是处于学习状态，对于一些模式理解可能会存在一些偏差，希望能够指出，我也会及时修改出现的一些问题。
单一职责原则：
单一职责原则英文名：Single Responsibility Principle，简称SRP原则。这一原则解释起来可能比较抽象，我刚刚开始学习的时候也是一脸懵逼，先把原话放出来吧，它的定义是这样的：
There should never be more than one reason for a class to change.
翻译过来就是：引起一个类发生改变的因素不应该有一个以上。
我们可以这样想，一个类要发生改变，那原因可能源自功能需求的变动（这里说的是职责，只谈论功能方面），那么因为功能性变动的原因不应该超过一个，大致就是说我们的职责应该只限于做单独一件事情。网上有的就解释的更加直接了：“一个类就应该只做一件事”。
注意：上面虽然说的是类，但是不只针对于类，接口，方法，类等都适用。
其次，很多情况我们并不需要一定满足单一职责原则，实际还是以具体业务情况为主。
下面就使用一个简单的例子来说明一下这个情况：
场景：
这里我们以餐厅为场景来模拟，假设员工的职责靠制服区分，制服代表某一类员工，开始的时候制服统一，厨师和洗菜人都是穿这样一件衣服，所以难免会出现分辨不清员工职责的情况，有时候会叫错洗菜人去做菜，因为制服没法好好区分职责。
后来，根据单一职责原则，我们一件制服代表一种职能，这样使用两套制服就可以区分开厨师和洗菜人，就不会出现叫错人做错事的情况。
改进前：
有一家饭店，开始招了一个厨师，招聘要求是会做饭洗菜。这时候就大明就来应聘了，饭店给员工制作并发放了统一员工制服（ICooker）
ICooker：
public interface ICook
{
void cleanFood(); // 洗菜
void cookMeal(); // 煮菜
}
DaMing：
public class DaMing implements ICooker
{
public void cleanFood()
{
System.out.println("洗菜...");
}
public void cookMeal()
{
System.out.println("煮菜...");
}
}
可能你认为这个接口设计也没多大问题，可是有一天，饭店做大了，厨师大明也越来越忙，事情已经做不急了，于是找来了一个负责洗菜的助手小明，由于之前只设计了一种制服，所以也发了同样的制服（ICooker），小明便开始在这里工作了。
XiaoMing:
public class XiaoMing implements ICooker
{
public void cleanFood()
{
System.out.println("洗菜...");
}
public void cookMeal()
{
System.out.println("菜烧坏了...");
}
}
突然有一天，大明去了一趟厕所，这时候有人不小心把小明当作厨师，因为制服都是统一的，以为也是厨师，于是就叫他去做菜了，这下好了，菜直接烧坏了。（我们方法大多时候使用的形参是接口对象，小明继承自ICooker，所以使用ICooker对象的地方可以使用小明，编译时不会产生错误，在使用时错误才会出现）
改进后
这时候老板就意识到问题了，因为制服穿得统一了，所以导致有人就分不清厨师和洗菜的人了，于是老板就心生一计，就重新设计了两类制服，一类给厨师（ICooker），一类给洗菜的人（IWasher），这样一来，所有人都不会叫洗菜的人去做菜了。
ICooker：
public interface ICooker
{
void cookMeal(); // 煮菜
}
IWasher：
public interface IWasher
{
void cleanFood(); // 洗菜
}
这时候，大明和小明的类就可以像如下设计了：
DaMing：
public class DaMing implements ICooker,IWasher
{
public void cookMeal()
{
System.out.println("做菜...");
}
public void cleanFood()
{
System.out.println("洗菜...");
}
}
XiaoMing：
public class XiaoMing implements IWasher
{
public void cleanFood()
{
System.out.println("洗菜...");
}
}
这时候每个人就用做自己的事情就好了。
先说下这样做的一个好处：
- 代码可读性高
- 可维护性高，变更风险小
- 降低了类的复杂性
但是这样也有不好的地方：
- 过多的类可能会导致类过多增加，最后只能通过组合或聚合的方式耦合在一起，这样一来，就又人为增加了类的复杂性。
其实这里看起来挺矛盾的，其实一看并不如此，因为设计的时候复杂性降低了，但是面对具体业务我们又不得不把某些东西组合在一起，这样一来，复杂性又增加了。所以最佳方式并不是无底线地遵循单一职责原则，而是在特定场合，打破或者是适度地遵循单一职责原则。