单一职责原则
例1:
大家应该能看出来这个类图中的接口设计是有问题的,用户的属性和用户的行为没有分开。
我们根据用户的属性和行为拆开这个接口。
![](http://hi.csdn.net/attachment/201111/26/0_13223118067HC3.gif)
重新拆分成两个接口,IUserBo 负责用户的属性,IUserBiz负责用户的行为。当我们实例化除UserINfo这个对象后,我们可以把UserInfo当做IUserBo实现类使用也可以将它当做IUserBiz的实现类使用,这就要看我们用在什么地方了。如果是获取用户信息,就把UserInfo 当做IUserBOSS的实现类,如果是维护用户信息,就当做是IUserBiz的实现类。
在实际应用中我们更倾向于把一个接口拆分成两个,一个是IUserBO一个是IUserBIz。类图如下。
这样做以后,我们就把一个接口拆成了两个,这样就符合了单一职责原则,那么什么是单一职责原则呢?
单一职责原则,核心思想是:一个类,最好只做一件事,只有一个引起它变化的原因。
单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申,将职责定义为引起变化的原因,以提高内聚性来减少引起变化的原因。职责过多,可能引起变化的原因就越多,这将是导致职责依赖,相互之间就产生影响,从而极大的损伤其内聚性和耦合度。单一职责通常意味着单一的功能,因此不要为类实现过多的功能点,以保证实体只有一个引起它变化的原因。
例2:
![](http://hi.csdn.net/attachment/201111/26/0_1322312028cac7.gif)
Rectangle拥有两个方法,一个方法是draw,用来画图形,另一个方法是area用来计算面积。
Rectangle违背了单一职责原则,因为它具有两个职责:计算面积与绘制矩形。
绘制图形会与用户界面有关,但是计算图形面积却未必与界面有关,如果把这两个职责写到一个类中,那么如果只需要使用area()方法这一职责来计算面积,那就不得不把draw()方法一同编译,但是却可能也用不到它。
如果其中一个职责需要修改,就不得不重新编译和部署另外一个。
如果类的职责超过一个,这些职责之间就会产生耦合。改变一个职责,可能会影响和妨碍类为其它类服务的功能。
把两个职责分开会好一些。
![](http://hi.csdn.net/attachment/201111/26/0_13223121106337.gif)
两个职责分离,这样耦合度就会降低。
SRP
原则的核心就是要求对类的改变只能是一个,对于违反这一原则的类应该进行重构,例如以Façade模式或Proxy模式分离职责,通过基本的方法Extract Interface、Extract Class和Extract Method进行梳理。
例3:
看一下下面的接口
public interface Phone
{
//拨通电话
public void dial(string phoneNumber);
//通话
public void chat(object o);
//回应
public void answer(object o);
//通话完毕
public void huangup();
}
这个接口有问题吗?
还真有问题。单一职责要求一个接口或者类只有一个原因引起变化,也就是一个接口或者类只有一个职责,它负责一件事情。
Phone这个接口不是一个职责,它是有两个职责:一个是协议管理,一个是数据传输。diag()和huangup()这两个方法实现的是协议管理,拨号和挂断。chat()和answer()是数据传输。协议改变和数据传输都会引起类的变化,那么我们就不能说它是符合单一职责原则。
由于这两个职责变化不互相影响,那么就考虑拆成两个接口。
![](http://hi.csdn.net/attachment/201111/26/0_1322312434Rb7N.gif)
这个类图已经符合单一职责原则,但是却复杂多了,组合是一种强耦合关系,两者都有共同的生命期,这种强耦合增加了类的复杂性,我们修改一下。
![](http://hi.csdn.net/attachment/201111/26/0_1322312492KnlT.gif)
这样设计才完美,一个手机实现两个接口,把两个职责融合一个类中,虽然你会觉得这个phone类有两个原因引起变化,但是我们是面向接口编程,对外公布的是接口,而不是实现类。如果非要使得类符合单一职责原则,那么就要使用上一个类图了,但是这样的话类的耦合性就增加了。
单一职责原则的好处:
类的复杂性降低
可读性提高
可维护性提高
变更引起的风险降低