我在差不多半年前读过这样一本书,《Head First 设计模式》,当时就被设计模式这四个字吸引了,曾经一度让我有了初恋般的感觉。但是没想着,做点记录,现在挺后悔的,所以差不多把设计思想又还给作者。这次重拾设计模式,就要开始做记录啦,写的不好的地方,多多包涵。献上一句我做喜欢的话,“三十年河东,三十年河西,莫欺少年穷”。
在六大设计原则里面,单一职责原则是最引人们争议的,下面我们就围绕这几个问题来进行记录。
- 单一职责原则的官方定义是什么?
- 为什么会引起人们的争议?
- 在现实开发中,我们采取的折中措施是什么?
- 单一职责原则的好处是什么?
先来解决第一个问题,单一职责原则的定义是什么?
单一职责原则的定义是:应该有且仅有一个原因引起类的变更。
那为什么会引起人们的争议呢?
单一职责原则规定,一个职责一个接口,但是职责并没有一个量化的标准。下面来看一个例子。
T先生要写一个电话的类,他思考着,呀,我刚学了单一职责原则,就一个职责嘛!于是他写了这样一个类。
public interface Iphone {
//拨通电话
public void dial(String phoneNumber);
//通话
public void chat(Object o);
//通话完毕
public void hangup();
}
只是T先生写的电话的类图:
正在这时,Z先生刚好路过,看到信心满满的T先生,说,“你这不对啊,这个接口里面是单一原则吗?这里面好像包含这两个职责吧,你看看是不是我说的这样,这个接口包含了,电话接通与通话的信号的转化(这里我们可以理解为我们可以用移动,也可以用电信呀)”,所以类图应该是这样画的。
这时孟先生刚好过来,孟先生是公司的CTO嘛,看手下的小伙伴谈论的这么热烈,也加入了讨论。Z先生啊,你的想法是完全正确的,接口和类都实现了单一原则,但是,注意但是!!!你这样子给我们的项目增加了很多的实现单一接口的类,还有Phone里面出现了组合,这极大地增强了代码的耦合性。T先生呢,你这样子的设计也没有大的问题,在项目工期如果紧急的话,我还是建议你这样做,那下面我折中来给你们画一个类图吧。
孟先生画完图,就潇洒地走了。
总结,一个职责对应一个接口,接口一定要做到单一职责,类的设计尽量做到单一职责。同样方法也要遵循单一原则,即一个方法执行一项功能。