管理与技术之方法（接口）行参与返回请用实体类

前言

会用与灵活的用好之间是妙之巅豪，失之千里。小细节大管理与大效率，管理没有大小之分, 很小的细节管理可能会很大在个个方面提升效率，降低成本。本章节是鸟菜啊在多年开发中一直使用的规则。方法（借口）行参与返回只用实体类

说一个真实的故事
刚刚到一个新小组，在一次会议的时候。
鸟菜啊：以后所有的方法（接口）行参与返回只用实体类
老员工A说：这不是增加了很多工作量吗？
新员工B说：是啊，很麻烦啊。
鸟菜啊：就这样定了，先执行吧。
..... 很久之后，老员工A去其他小组了
某天
老员工A对其他人说：方法（接口）行参与返回要用实体类
鸟差啊听了哈哈大笑

好处

1. 保持接口的单一性与向前兼容
2. 减少维护工作量
3. 介绍沟通成本

保持接口的单一性

第一阶段 只需要通过用户id查询用户信息

public class UserController{

	public UserInfo getUserInfo(Long userId){
	
	}
}

第二阶段需求 需要通过 userId 与 appId 得到用户

public class UserController{

	@RequestMapping("getUserInfo")
	public UserInfo getUserInfo(Long userId ){
	}
	@RequestMapping("newGetUserInfo")
	public UserInfo getUserInfo(Long userId , Long appId){
	}
}

1. 如果为了保持向前兼容需要保留以前的方法，在添加新方法。同时需要维护两个接口，还需要与其他人通过新接口，成本增大。
2. 如果不新增接口，那么 getUserInfo(Long userId , Long appId)需要同时处理UserId与 UserId和AppId的行为，那么对接方需要全部修改，影响人数太多了。

如果使用实体类

第一阶段 只需要通过用户id查询用户信息

public class UserController{

	public UserInfo getUserInfo(UserInfo userInfo){
	
	}
}

第二阶段需求 需要通过 userId 与 appId 得到用户

public class UserController{

	public UserInfo getUserInfo(UserInfo userInfo){
	}
}

接口的定义与声明根本就没有发生变化，

减少维护工作量

public class UserController{

	public UserInfo getUserInfo(Long userId){
	
	}
}

public Implementation UserServer{
	public UserInfo getUserInfo(Long userId);
}

public class UserServerImpl Implementation UserServer{
	public UserInfo getUserInfo(Long userId);
}

public class UserDao{
	public UserInfo getUserInfo(Long userId);
}

当发生修改的时候

public class UserController{

	public UserInfo getUserInfo(Long userId  , AppId appId){
		userServer.getUserInfo( userId ,  appId);
	}
}

public Implementation UserServer{
	public UserInfo getUserInfo(Long userId , AppId appId);
}

public class UserServerImpl Implementation UserServer{
	public UserInfo getUserInfo(Long userId  , AppId appId){
		return userDao.getUserInfo( userId ,  appId)
	}
	
}

public class UserDao{
	public UserInfo getUserInfo(Long userId  , AppId appId);
}

需要找到每个接口与类，打开，修改.....调试等等操作。

如果使用对象，只需要修改sql语句就行了。这叫不变应万变。

代码更加简洁，规范，容易懂

不好范例

public class UserController{

	@RequestMapping("getUserInfo")
	public UserInfo getUserInfo(Long userId ){
	}
	@RequestMapping("newGetUserInfo")
	public UserInfo appIdAndUserIdGetUserInfo(Long userId , Long appId){
	}
	
	@RequestMapping("newGetUserInfo")
	public UserInfo ageAndUserIdGetUserInfo(Long uId , Long age,){
	}
}

上面形参userId与uId其实是一个意识，但是因为开发人员忽视或者由不同开发人员开发，每个人的行为习惯不一样。操作形参命名不同，造成维护与沟通成本剧增。

好的范例

一个接口就可以搞定了。由mybatis去识别下参数。

public class UserController{

	@RequestMapping("getUserInfo")
	public UserInfo getUserInfo(UserInfo userInfo ){
	}
}

代码更加简洁，规范，容易懂

不好范例

public class UserController{

	@RequestMapping("getUserInfo")
	public UserInfo getUserInfo(Long userId ){
	}
	@RequestMapping("newGetUserInfo")
	public UserInfo appIdAndUserIdGetUserInfo(Long userId , Long appId){
	}
	
	@RequestMapping("ageAndUserIdGetUserInfo")
	public UserInfo ageAndUserIdGetUserInfo(Long userId , Long age, Long appid){
	}
}

好的范例

不管加多少个接口或者多少个Controller，只要看到UserInfo对象。调用者基本知道这方法作用和行为。不需要在去理解参数。

public class UserController{

		@RequestMapping("getUserInfo")
	public UserInfo getUserInfo(UserInfo userInfo ){
	}
	@RequestMapping("newGetUserInfo")
	public UserInfo appIdAndUserIdGetUserInfo(UserInfo userInfo){
	}
	
	@RequestMapping("ageAndUserIdGetUserInfo")
	public UserInfo ageAndUserIdGetUserInfo(UserInfo userInfo){
	}
	......
}

public class UserLogController{

		@RequestMapping("getUserInfo")
	public UserInfo getUserLog(UserInfo userInfo ){
	}
	......
}

千万不要在实体与其他传输对象之间转化

实体与xxxInput和xxxOnput转换

public class UserController{

	@RequestMapping("getUserInfo")
	public UserInfo getUserInfo(UserInfoInput userInfoInput ){
		UesrInfo userInfo = new UserInfo();
		userInfo.setUid(userInfoInput.getUid());
		userInfo.setName(userInfoInput.getName());
		userInfo.setAge(userInfoInput.getAge());
		userInfo.setAppId(userInfoInput.getAppId());
		userInfo.setAddree(userInfoInput.getAddree());
		// 进行一些业务操作
		
		UesrInfoOuput userInfoOuput = new UesrInfoOuput();
		userInfoOuput.setUid(userInfo.getUid());
		userInfoOuput.setName(userInfo.getName());
		userInfoOuput.setAge(userInfo.getAge());
		userInfoOuput.setAppId(userInfo.getAppId());
		userInfoOuput.setAddree(userInfo.getAddree());
	}
}

1. 与他人合作开发一个模块，一个类里面600行代码，其中300多行代码是各种实体与OUput与input的转换，直接看崩了。
2. 在一些复杂的业务中，数据对象之间的转换是十分难以理解，阅读的。
3. 需要消耗大量的时间，创建input与ouput对象，目录。大大的提高了开发成本，维护成本。

有些会问返回的时候，不想别人知道映射关系。这个问题很简单。

1. 字段命名与变量命名不同。
2. mybatis映射不同
3. json序列化的时候，命名不同就行了。

总结

简单就是美，管理与架构的本质是提高效率，而大量的数据对象转换，从而大大的降低了效率。得不偿失。

转载于:https://my.oschina.net/u/1261452/blog/3102405