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

前言

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

说一个真实的故事
刚刚到一个新小组，在一次会议的时候。
鸟菜啊：之后全部的方法（接口）行参与返回只用实体类
老员工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序列化的时候，命名不一样就好了。

总结

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