单一职责原则

?一个优良的系统设计，强调模块间保持低耦合、高内聚的关系，在面向对象设计中这条规则同样适用，所以面向对象的第一个设计原则就是：单一职责原则（SRP，Single Responsibility Principle）。

• 定义

单一职责原则(Single Responsibility Principle,SRP)：一个类，最好只做一件事，只有一个引起它变化的原因。

• 理解

理解SRP的关键在于理解类的抽象层次，高层次的类是高层概念的抽象，低层次的类是低层概念的抽象。低层的变化只影响低层类，高层的变化只影响高层类。对于遵守SRP的设计，一定具有很好的抽象层次，因此不妨以SRP为指导和检验，帮助我们设计出好的类来。最后，我用几个关键词梳理SRP的脉络：类只有一个变化的原因 >> 一个变化只影响一个类 >> 变化只影响其相应层次的类

SRP由引起变化的原因决定，而不由功能职责决定。虽然职责常常是引起变化的轴线，但是有时却未必，应该审时度势。

?基于这两点理解，引发出我的观点：

1. ?对象颗粒大小不同，对小颗粒对象应用单一职责是不合适的：小颗粒对象如小公司的员工，需要一人兼数职。如果应用单一职责，小颗粒对象又将分解成更多更小颗粒的对象，数量越来越多，给我们命名、使用、维护带来麻烦。
2. 基础类库不适合：比如字符串常用处理的类，取子字符串、转换为其它类型、为空判断，放在一个类中反而使用更方便！
3. “单一职责原则”更适于中大型系统，系统越小使用该原则越不划算：一超个小系统就一个界面，面象对象都不必使用。
4. ?单一职责当然要用，但不是用到每个细节：一些局部不用对整体影响很小，反而更灵活、更省时间。?
5. ?原则是前辈能多年的经验总结出来的，原则的名字可能不变，但原则的内含可能在悄悄变化。
6. ?“principle”、“原则”有可能是前人一种表达强烈建议的方式，而不是“must”、“必须”。
7. 只有逻辑足够简单，才可以在代码级别上违反单一原则；只有类中的方法数量足够少，才可以在方法级别上违反单一职责原则