设计原则思想

lesson 1:单一职责原则

        一个类或者模块只负责完成一个职责。

        如何判断类的职责是否足够单一？举一个例子：下面这个userinfo类来记录用户的信息，可以看到地址的权重比较大，那是否要拆分出去呢？

 
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类中，所占的比重比较高，可以继续拆分成独立的useraddress类，userinfo只保留除Address之外的其他信息，拆分之后的两个类的职责更加单一。如果社交产品发展的比较好，之后又在产品中添加了电商的模块，用户的地址也会用在电商物流中，那么第二点更加的合适

        什么时候需要对类进行拆分？

•    类中代码行数、函数或属性过多，那么就需要考虑对类进行拆分
• 类依赖其他类过多，或者依赖类的其他类过多，不符合高内聚、低耦合思想
• 私有方法过多，考虑是否可以拆分出新的类中，写成public方法，供更多类使用
• 比较难给一个类起名字
• 类中大量方法都是集中操作类中的几个属性

lesson 2:开闭原则

        添加一个新的功能应该是在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）。每当需要重新之前接口的之后，就要想到能否重构，满足开闭原则。

        最常用来提高代码可扩展性的方法有：多态、依赖注入、基于接口而非实现编程。以及大部分的设计模式：装饰、策略、模板、职责链、状态等。