软件设计原则—-单一职责原则（SRP）http://blog.csdn.net/beyondhaven/article/details/6821010

软件设计原则—-单一职责原则（SRP）

陈述：

就一个类而言，应该只有一个导致其变化的原因

分析：
一个职责就是一个变化的轴线。
一个类如果承担的职责过多，就等于将这些职责耦合在一起。一个职责的变化可能会虚弱或者抑止这个类完成其它职责的能力。

多职责将导致脆弱性的臭味。

示例1：

示例2：
一个Modem的接口：

1. Class Modem{  
2.     public:   
3.     virtual void dail(char* pno)=0;  
4.     virtual void hangup( ) =0;  
5.     virtual void send(char c) =0;  
6.     virtual void recv( ) =0;  
7. };  

Modem类（可能）有两个职责：

• 拨
• 通信

–什么是职责/span>
职责是“变化的原因”。
–上面的例子可能存在两种变化的方式：

• 连接和通信可能独立变化

在这种情况下，应该将职责分开。例如，应用的变化导致了连接部分方法的签名（signature）发生了变化，那么使用数据连接的部分也需要重新编译、部署，这会相当麻烦，使得设计僵化。

• 连接和通信同时变化

这种情况下，不必将职责分开。反而分离可能导致“不必要的复杂性”的臭味

修改后的设计如下：

单一职责原则的好处：

• 类的复杂性降低，实现什么职责都有清晰明确的定义；
• 可读性提高，复杂性降低，可维性提高；
• 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影

响，对其他接口无影响，对系统的扩展性、维护性有较大的帮助。

常见错误提醒：

•  持久化与业务规则的耦合。

Employee类包含了业务规则和对持久化的控制。
业务规则经常变化，而持久化方法却一般不变，而且变化原因也完全不同。将这两个职责耦合在一起，将导致每次因为业务规则变化调整Employee类时，所有持久化部分的代码也要跟着变化

小结：

• 如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。
• 我们会自然地把职责结合在一起。如果能想到多于一个动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。
•  软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。
• SRP是所有原则中最简单、也是最难运用的。其余原则会以这样或那样的方式回到这个问题上。
• 单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口类或类设计得是否好，但“职责”和“变化原因”都是
  不可度量的，因项目而异，依环境而异。
• 单一职责原则很难在项目中得到体现。考虑工期、成本、人员技术水平、硬件情况甚至项目之外的因素。
• 建议：接口一定做到单一职责，类的设计尽量做到只有一个原因引起变化。
  

文章知识点与官方知识档案匹配，可进一步学习相关知识 络技能树首页概览22084 人正在系统学习中