理论一：对于单一职责原则，如何判定某个类的职责是否够“单一”？

SOLLD:

S    ->    SRP->    Single Responsibility Principle

A class  or  module should have a single responsiblity。

一个类或者模块只负责完成一个职责（或功能）

所谓职责单一的划分：对应于不同的应用场景和需求；（炒菜放一点点盐）

先是一个粗粒度的类满足业务需要，随着业务发展，粗粒度的类越来越庞大，划分成更细粒度的类（持续重构）；

判断的几条准则：

    类中的代码行数、函数或属性过多时，而影响代码的可读性和可为维护性时；

    类依赖的其他类过多、或者依赖类的其他类过多，不符合高内聚、低耦合的设计思想；

    很难用一个业务名称给一个类起名时；

    类中的大量方法都集中操作类中的某几个属性；

    私有方法过多；（保留意见）

注意：类的职责并不是越单一越好

    单一原则是通过 避免设计大而全的类，避免将不相干的功能耦合在一起；低耦合；

    当功能有很深的关系（序列化与反序列化）则需要放到同一个类里面；高内聚；