The Single Responsibility Principle（单一职责SRP）
有时候，开发人员设计接口的时候会有些问题，比如用户的属性和用户的行为被放在一个接口中声明。这就造成了业务对象和业务逻辑被放在了一起，这样就造成了这个接口有两种职责，接口职责不明确，按照SRP的定义就违背了接口的单一职责原则了
按字面意思理解单一职责原则，就是功能要单一？
A class should have only one reason to change
所谓单一职责，就是一个设计元素只做一件事。什么是“只做一件事”？简单说就是少管闲事。现实中就是如此，如果要你专心做一件事情，任何人都有信心可以做得很出色。但如果，你整天被乱七八糟的事所累，还有心思和精力把每件事都作好么？
为什么需要分离职责？
想想我们日常的开发一个功能，是不是喜欢把什么逻辑都写到一个类中，算法，UI结构，渲染，数据库操作等等，当然你就会说这本来就是一个单独的功能块，是的，没错，但是如果要再开发一个类似的功能块，是不是又要重写一遍呢？ 复用基本就变成不可能了. 此时如果有变动，你需要同时改变2个功能块的相似代码了，这里在抽象代码的复用同时强调分类后每个类都有自己的职责。
如何分离职责？
我估计这也是最难的地方，在一个功能设计中，我可能知道不合理，但是不知道怎么分离职责！
我们来看看jQuery
jQuery的API规范比较合理，可以看看 css(),attr(),ajax(),animate(),每一个接口对应的功能职责很单一，这是从功能抽象的角度
如果细分的话css 还要区分set 与 get， 这样貌似就与职责单一有违背了，但是jQuery这种反模式设计深受开发者喜欢
但是如果我们给自己的一个功能块提供写set类 然后通过传递set(‘css’),set(‘sttr’),set(‘animate’),这样问题就很明显了
一个set类承担的职责太多了，可以操作css,还能操作attr,还能操作动画，set类把所有的功能都写在一个模块中了，等于把这些职责耦合在一起
一个职责的变化会削弱或者抑制这个类完成其他职责的能力，这种耦合的设计是很脆弱的，出问题的几率也会增大
那么分离的原则就是：
如果能够想到多于一个的动机去改变这个类，那么这个类就具体有多一于一个的职责，可以考虑分离
那么单一职责原则的意义何在呢？
- 降低类的复杂性，实现什么样的职责都有清晰的定义
- 提高可读性
- 提高可维护性
- 降低变更引起的风险，对系统扩展性和维护性很有帮助
但是、使用单一职责原则有一个问题，“职责”没有一个明确的划分标准，如果把职责划分的太细的话会导致接口和实现类的数量剧增，反而提高了复杂度，降低了代码的可维护性。所以使用这个职责的时候还要具体情况具体分析。建议就是接口一定要采用单一职责原则，实现类的设计上尽可能做到单一职责原则，最好是一个原因引起一个类的变化。