单一职责原则-SRP
################

* Single Responsibility Principle

.. note:: A class or module should have a single responsibility

问题:这个实例是否满足单一职责原则呢::

    public class UserInfo {
      private long userId;
      private String username;
      private String email;
      private String telephone;
      private long createTime;
      private long lastLoginTime;
      private String avatarUrl;
      private String provinceOfAddress; // 省
      private String cityOfAddress; // 市
      private String regionOfAddress; // 区 
      private String detailedAddress; // 详细地址
      // ...省略其他属性和方法...
    }

解答:我们不能脱离具体的应用场景::

    1. 如果在这个社交产品中，用户的地址信息跟其他信息一样，只是单纯地用来展示，那 UserInfo 现在的设计就是合理的。
    2. 如果这个社交产品发展得比较好，之后又在产品中添加了电商的模块
        用户的地址信息还会用在电商物流中，那我们最好将地址信息从 UserInfo 中拆分出来，
        独立成用户物流信息（或者叫地址信息、收货信息等）。
    3. 如果做这个社交产品的公司发展得越来越好，公司内部又开发出了很多其他产品（可以理解为其他 App）
        公司希望支持统一账号系统，也就是用户一个账号可以在公司内部的所有产品中登录。
        这个时候，我们就需要继续对 UserInfo 进行拆分，将跟身份认证相关的信息（如email、tel）抽取成独立的类


.. note:: 不同的应用场景、不同阶段的需求背景下，对同一个类的职责是否单一的判定，可能都是不一样的。在某种应用场景或者当下的需求背景下，一个类的设计可能已经满足单一职责原则了，但如果换个应用场景或着在未来的某个需求背景下，可能就不满足了，需要继续拆分成粒度更细的类。


.. note:: 评价一个类的职责是否足够单一，我们并没有一个非常明确的、可以量化的标准，可以说，这是件非常主观、仁者见仁智者见智的事情。实际上，在真正的软件开发中，我们也没必要过于未雨绸缪，过度设计。所以，我们可以先写一个粗粒度的类，满足业务需求。随着业务的发展，如果粗粒度的类越来越庞大，代码越来越多，这个时候，我们就可以将这个粗粒度的类，拆分成几个更细粒度的类。这就是所谓的持续重构



小技巧:指导意义和可执行性的几条判断原则::

    1. 类中的代码行数、函数或属性过多
        会影响代码的可读性和可维护性，我们就需要考虑对类进行拆分；
    2. 类依赖的其他类过多，或者依赖类的其他类过多
        不符合高内聚、低耦合的设计思想，我们就需要考虑对类进行拆分；
    3. 私有方法过多
        我们就要考虑能否将私有方法独立到新的类中，设置为 public 方法，供更多的类使用，从而提高代码的复用性；
    4. 比较难给类起一个合适名字
        很难用一个业务名词概括，或者只能用一些笼统的 Manager、Context 之类的词语来命名，
        这就说明类的职责定义得可能不够清晰；
    5. 类中大量的方法都是集中操作类中的某几个属性
        比如，在 UserInfo 例子中，如果一半的方法都是在操作 address 信息，
        那就可以考虑将这几个属性和对应的方法拆分出来。


.. note:: 不管是应用设计原则还是设计模式，最终的目的还是提高代码的可读性、可扩展性、复用性、可维护性等。我们在考虑应用某一个设计原则是否合理的时候，也可以以此作为最终的考量标准。