设计模式原则（1）单一职责原则

单一职责（SRP，Single Responsibility Principle），这本是一个常识。但在实际的开发中却往往难以做到。

何为单一职责？原话解释是：“There should never be more than one reason for a class to change”；应该有且仅有一个原因引起类变更。

单一职责使得代码设计的边界更加清晰，每个接口、类、方法的职责都可以很明确。其有如下优点：
1、降低了类的复杂度以及变更引起的风险
2、提高了代码可读性以及可维护性

举一个例子，在进行用户类设计时，往往会将属性、行为分别抽象出一个或多个接口。而在接口中可能会有修改用户姓名、密码、电话号码等相关信息的操作方法。到这里就已经不止一次涉及到SRP了；就比如在进行接口设计时是将属性、行为放在一起吗？修改用户信息时你是直接用changeUserInfo还是使用changeUserName、changeUserPwd、changeUserTel的方式呢？相信以上问题对于一个稍有经验的程序员来说都不在话下，嗯，可能还会不屑；这都是啥问题 ?能不能整些水准的哦！

可是在实际复杂大型的项目开发中，对于职责的粒度定义却又难以把控，进而影响着代码的设计。就比如说在复杂的业务逻辑中，一昧的追求类的单一职责可能会引起类数量的激增，从另一方面增大了项目开发维护的难度；不要忘了所有的开发原则都是为了更好的服务项目开发，原则是普世规律的抽象，却不一定完全适用于多变的环境（通常情况下是这样的）。这类似于数仓建模时的反范式设计理念。很多时候我们需要在原则和实际运用场景之间做出权衡。“This is sometimes hard to see”
当然，如果你设计出了changeUserInfo这样的接口方法，就等着leader找你谈话吧！

问题来了。你先看看以往自己写的代码，有严格遵循SRP吗？很遗憾，很多都没有。

参考文献
秦小波《设计模式之禅 》第二版