（转）重述——单一职责原则

[size=medium][b]单一职责原则(Single Responsibility Principle SRP)[/b][/size]
There should never be more than one reason for a class to change.

什么意思呢？
所谓单一职责原则就是[b]一个类只负责一个职责，只有一个引起变化的原因。[/b]
如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化会削弱或抑制这个类完成其他职责的能力，这个耦合会脆弱的设计。
软件设计真正要做的许多内容，就是[b]发现职责并把这些职责相互分离；如果能够想到多于一个动机去改变一个类，那么这个类就具有多于一个职责，就应该考虑类的分离。[/b]
以调制解调器为例如下图：
[img]http://dl2.iteye.com/upload/attachment/0090/6416/cd0b9024-09d5-340b-9a6f-f1a772cae32f.jpg[/img]　　　　　　　　　　　　　　　　　　　　　　
从上述类图里面我们发现有四个方法Dial(拨通电话)，Hangup(挂电话)，Receive(收到信息)，Send(发送信息)，经过分析不难判断出，实际上Dial(拨通电话)和Hangup(挂电话)是属于连接的范畴，而Receive(收到信息)和Send(发送信息)是属于数据传送的范畴。这里类包括两个职责，显然违反了SRP。
这样做有潜在的隐患，如果要改变连接的方式，势必要修改Modem，而修改Modem类的结果导致凡事依赖Modem类可能都需要修改，这样就需要重新编译和部署，不管数据传输这部分是否需要修改。
因此要重构Modem类，从中抽象出两个接口，一个专门负责连接，另一个专门负责数据传送。依赖Modem类的元素要做相应的细化，根据职责的不同分别依赖不同的接口。如下图：

[img]http://dl2.iteye.com/upload/attachment/0090/6418/272e0ec8-f26e-3fb2-bd05-58f835dd4d16.jpg[/img]
这样以来，无论单独修改连接部分还是单独修改数据传送部分，都彼此互不影响。
总结单一职责优点：
[list]
[*] 降低类的复杂性，
[*] 提高可维护性
[*] 提高可读性。
[/list]
降低需求变化带来的风险。需求变化是不可避免的，如果单一职责做的好，一个接口修改只对相应的实现类有影响，对其它的接口无影响，这对系统的扩展性和维护性都有很大的帮助。

原文链接：[url]http://www.cnblogs.com/shaosks/archive/2012/02/02/2335478.html[/url]