标签：相互 bsp 部署 nbsp 分享 信息 调制解调器 包括 帮助
There should never be more than one reason for a class to change.
什么意思呢？
所谓单一职责原则就是一个类只负责一个职责，只有一个引起变化的原因。
如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化会削弱或抑制这个类完成其他职责的能力，这个耦合会脆弱的设计。
软件设计真正要做的许多内容，就是发现职责并把这些职责相互分离；如果能够想到多于一个动机去改变一个类，那么这个类就具有多于一个职责，就应该考虑类的分离。
以调制解调器为例如下图：
从上述类图里面我们发现有四个方法Dial(拨通电话)，Hangup(挂电话)，Receive(收到信息)，Send(发送信息)，经过分析不难判断出，实际上Dial(拨通电话)和Hangup(挂电话)是属于连接的范畴，而Receive(收到信息)和Send(发送信息)是属于数据传送的范畴。这里类包括两个职责，显然违反了SRP。
这样做有潜在的隐患，如果要改变连接的方式，势必要修改Modem，而修改Modem类的结果导致凡事依赖Modem类可能都需要修改，这样就需要重新编译和部署，不管数据传输这部分是否需要修改。
因此要重构Modem类，从中抽象出两个接口，一个专门负责连接，另一个专门负责数据传送。依赖Modem类的元素要做相应的细化，根据职责的不同分别依赖不同的接口。如下图：
这样以来，无论单独修改连接部分还是单独修改数据传送部分，都彼此互不影响。
总结单一职责优点：
降低类的复杂性，
提高可维护性
提高可读性。
降低需求变化带来的风险。需求变化是不可避免的，如果单一职责做的好，一个接口修改只对相应的实现类有影响，对其它的接口无影响，这对系统的扩展性和维护性都有很大的帮助。
标签：相互 bsp 部署 nbsp 分享 信息 调制解调器 包括 帮助
原文地址：http://www.cnblogs.com/mamxfx/p/7148055.html
