六大设计原则，单一职责原则

我在差不多半年前读过这样一本书，《Head First 设计模式》，当时就被设计模式这四个字吸引了，曾经一度让我有了初恋般的感觉。但是没想着，做点记录，现在挺后悔的，所以差不多把设计思想又还给作者。这次重拾设计模式，就要开始做记录啦，写的不好的地方，多多包涵。献上一句我做喜欢的话，“三十年河东，三十年河西，莫欺少年穷”。

在六大设计原则里面，单一职责原则是最引人们争议的，下面我们就围绕这几个问题来进行记录。

1. 单一职责原则的官方定义是什么？
2. 为什么会引起人们的争议？
3. 在现实开发中，我们采取的折中措施是什么？
4. 单一职责原则的好处是什么？

先来解决第一个问题,单一职责原则的定义是什么？
单一职责原则的定义是：应该有且仅有一个原因引起类的变更。

那为什么会引起人们的争议呢？
单一职责原则规定，一个职责一个接口，但是职责并没有一个量化的标准。下面来看一个例子。
T先生要写一个电话的类，他思考着，呀，我刚学了单一职责原则，就一个职责嘛！于是他写了这样一个类。

public interface Iphone {
    //拨通电话
    public void dial(String phoneNumber);
    //通话
    public void chat(Object o);
    //通话完毕
    public void hangup();
}

只是T先生写的电话的类图：

正在这时，Z先生刚好路过，看到信心满满的T先生，说，“你这不对啊，这个接口里面是单一原则吗？这里面好像包含这两个职责吧，你看看是不是我说的这样，这个接口包含了，电话接通与通话的信号的转化（这里我们可以理解为我们可以用移动，也可以用电信呀）”，所以类图应该是这样画的。

这时孟先生刚好过来，孟先生是公司的CTO嘛，看手下的小伙伴谈论的这么热烈，也加入了讨论。Z先生啊，你的想法是完全正确的，接口和类都实现了单一原则，但是，注意但是！！！你这样子给我们的项目增加了很多的实现单一接口的类，还有Phone里面出现了组合，这极大地增强了代码的耦合性。T先生呢，你这样子的设计也没有大的问题，在项目工期如果紧急的话，我还是建议你这样做，那下面我折中来给你们画一个类图吧。

孟先生画完图，就潇洒地走了。

总结，一个职责对应一个接口，接口一定要做到单一职责，类的设计尽量做到单一职责。同样方法也要遵循单一原则，即一个方法执行一项功能。