设计模式之六大原则——单一职责原则(SRP)

http://www.cnblogs.com/muzongyan/archive/2010/08/03/1791331.html

 

定义：

应该有且仅有一个原因引起类的变更。

There should never be more than one reason for a class to change.

 

优点：

1、类的复杂性降低，实现什么职责都有清晰明确的定义；

2、可读性提高，复杂性减低，可读性当然提高；

3、可维护性提高，可读性提高，可维护性当然提高；

4、变更引起的风险减低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的类有影响，对其他接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

 

注意：

单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。

 

建议：

接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。

 

=================

http://www.cnblogs.com/sevenyuan/archive/2010/03/05/1678730.html

1. 单一职责原则(SRP)

   “就一个类而言，应该仅有一个引起它变化的原因。”也就是说，不要把变化原因各不相同的职责放在一起，因为不同的变化会影响到不相干的职责。再通俗一点地说就是，不该你管的事情你不要管，管好自己的事情就可以了，多管闲事害了自己也害了别人。(当然这里说的多管闲事跟见义勇为是两回事，我们提倡见义勇为！)

       例如：参考下图中的设计，图形计算程序只使用了正方形的Area()方法，永远不会使用Draw()方法，而它却跟Draw方法关联了起来。这违反了单一原则，如果未来因为图形绘制程序导致Draw()方法产生了变化，那么就会影响到本来毫不关系的图形计算程序。

 

        那么我们该怎么做呢？如下图，将不同的职责分配给不同的类，使单个类的职责尽量单一，就隔离了变化，这样他们也不会互相影响了。