设计模式之单一职责原则的定义，个人理解，好处，以及使用

单一职责原则的英文名称是Single Responsibility Principle，简称是SRP。

单一职责原则的定义是：应该有且仅有一个原因引起类的变更。

SRP的原话解释是：
There should never be more than one reason for a class to change.

 

单一职责原则有什么好处：

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

● 可读性提高，复杂性降低，那当然可读性提高了；

● 可维护性提高，可读性提高，那当然更容易维护了；

● 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修

改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大

的帮助。

 

个人理解：在代码设计中不只是类要满足单一职责原则，方法和接口也要满足这个原则：

比如  public void changeUser(String name,String password ,String ... args){} 这个用于更改用户信息的方法，调用方法时可传入一个可变参数 进行用户信息修改，这样的方法就严重违反了单一指责原则，具体原因想必不必多言，正确的鞋码应该是public void changeUserName(String name){}。。。。一个方法只用于维护用户的一项信息。

对于接口，我们在设计的时候一定要做到单一，但是对于实现类就需要多方面考虑了。生搬硬套单一职责原则会引起类的剧增，给维护带来非常多的麻烦，而且过分细分类的职责也会人为地增加系统的复杂性。本来一个类可以实现的行为硬要拆成两个类，然后再使用聚合或组合的方式耦合在一起，人为制造了系统的复杂性。所以原则是死的，人是活的，这句话很有道理。

当我们在说到类的单一职责原则的时候，回头想想自己在真是开发中有多少类是满足单一指责原则的。是的，类的单一职责确实受非常多因素的
制约，纯理论地来讲，这个原则是非常优秀的，但是现实有现实的难处，你必须去考虑项目工期、成本、人员技术水平、硬件情况、网络情况甚至有时候还要考虑政府政策、垄断协议 等因素。

所以对于单一职责原则，我的建议是接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。