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:开闭原则
添加一个新的功能应该是在已有代码基础上扩展代码(新增模块、类、方法等),而非修改已有代码(修改模块、类、方法等)。每当需要重新之前接口的之后,就要想到能否重构,满足开闭原则。
最常用来提高代码可扩展性的方法有:多态、依赖注入、基于接口而非实现编程。以及大部分的设计模式:装饰、策略、模板、职责链、状态等。