管理與技術之方法（接口）行參與返回請用實體類

前言

會用與靈活的用好之間是妙之巔豪，失之千里。小細節大管理與大效率，管理沒有大小之分, 很小的細節管理可能會很大在個個方面提高效率，下降成本。本章節是鳥菜啊在多年開發中一直使用的規則。方法（藉口）行參與返回只用實體類

說一個真實的故事
剛剛到一個新小組，在一次會議的時候。
鳥菜啊：之後全部的方法（接口）行參與返回只用實體類
老員工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序列化的時候，命名不一樣就好了。

總結

簡單就是美，管理與架構的本質是提升效率，而大量的數據對象轉換，從而大大的下降了效率。得不償失。