工作日常--充血模型的思考

引言

因为刚入职不久,所以开发的功能会被CTO 审查,确保我确实有去看团队开发规范,而不是在划水…今天把我对接物流平台的功能看了下,点评内容:“可以在实体类中增加一些自洽的小方法,适当的将实体类充血来简化服务层,避免服务层混乱和过于复杂”

叨叨

什么自洽的方法,什么适当充血,我当时是懵的.我明白大致是说要我把服务层的一些> 方法放到实体类中.这种写法我之前也看到过,当时看到这种写法的时候心里在想:服务层简化了,实体类不又复杂了,换汤不换药,都是一些噱头…
自洽我是没理解,但是充血是啥,我赶紧搜索一波.一顿搜索下来,之前觉得只是换一种写法把一些方法挪到实体中,现在竟然不争气的表示赞同.关于这种充血模型,有一句话我觉得说的很好:面向对象开发,抽象的对象应该包含属性和行为.而不是仅仅作为ORM中数据载体.之前的开发团队要求entity实体类要保持整洁清爽,所有操作都在服务层做,即:

class Express{
	private String status;
	private String shipperCode;
	private String logisticsCode;
	//...
	// setter()
	// getter()
}
class ExpressService{
	
	Object queryTraces(String logisticsCode){
		// 是否存在该快递单号
		Express express = selectByLogisticsCode();
		// 物流状态是否已签收
		if (express.status >= StatusEnums.SIGN.getValue()) {
			// 直接查询DB
		} else {
			// 调用快递平台接口查询并落库
			queryApiAndSave2DB();
		}
	}
}

抽象出来的对象应该是具有行为的,而不应该仅仅是简单的数据载体,而对象应该具备哪些行为呢?这或许是最难的点,涉及到对象行为的界定,某个方法该不该在这里出现又涉及模块边界的划分,如果开发人员不能很好的理解模块设计者的初衷,就会出现我最初的那种看法,觉得方法抽取到哪里没多大影响,毕竟功能实现,而且这个设计多少带有一定的主观性.
至少现在我是认同对象应该具备行为的,改造下代码结构:

class Express{
	private String status;
	private String shipperCode;
	private String logisticsCode;
	//...
	// setter()
	// getter()
	
	// 物流状态是否已签收
	Boolean hasSign(){
		this.status >= StatusEnums.SIGN.getValue();
	}
}
class ExpressService{
	Object queryTraces(String logisticsCode){
		// 是否存在该快递单号
		Express express = selectByLogisticsCode();
		if (express.hasSign()) {
			// 直接查询DB
		} else {
			// 调用快递平台接口查询并落库
			queryApiAndSave2DB();
		}
	}
}

就是这简单的一个hasSign() 方法,虽然好像没啥区别,但我好像有点理解CTO大佬说的那个"自洽"的含义了,应该就是界定该行为放在实体类中是合适而不突兀的,符合OOP思想的,那么就是自洽的.而所谓的小方法其实就是实体类自身的一些无关业务的行为方法.比如这个hasSign 放在Express中会更合理,确实应该作为Express自身的行为.如果将服务层的一些实体类行为使用充血模型,确实也能简化服务层的逻辑.