導語

自2013年畢業後，今年已經是我工作的將近十個年頭了，總在做java相關的工作，終於有時間坐下來，寫一篇關於java寫法的一篇文章，來探討一下如果你真的是一個java程式設計師，那你真的會寫java嗎?筆者是一個務實的程式設計師，故本文絕非扯淡文章，文中內容都是乾貨，望讀者看後，能有所收穫。

文章核心

其實，本不想把標題寫的那麼恐怖，只是發現很多人幹了幾年java以後，都自認為是一個不錯的java程式設計師了，可以拿著上萬的工資都處宣揚自己了，寫這篇文章的目的並不是嘲諷和我一樣做java的同行們，只是希望讀者看到此騙文章後，可以和我一樣，心平氣和的爭取做一個優秀的程式設計師。

講述方向

由於一直從事移動網際網路相關工作，java開發中經常和移動端打交道或者做一些後端的工作，所以本篇文章更可能涉及和移動端的互動或者與後端的互動方式，筆者希望以自身的一些學習經驗或者開發經驗，可以帶動認真閱讀本篇文章的讀者們，讓大家對java有一個更好的態度去學習它，它不只是一個賺錢的工具而已。

筆者身邊有很多與筆者年齡相仿或年齡更大的朋友或同事，經常有人問我：“你現在還在學習嗎？我覺得沒什麼好學的，這些東西都差不多”，我總是回答只要有時間，我就要看一會書，這個時候，大家都會露出一副不屑的眼神或笑容。其實，非常能理解身邊朋友或同事的看法，以目前狀態來講，大多都是工作至少5年的程式設計師了，對於公司大大小小的業務需要，以目前的知識儲備來講，都可以輕鬆應對，“沒有什麼好學的”其實這句話沒有多大的問題，但是，如果你對程式設計還有一點點興趣，只是不知道如何努力或改進，希望本篇文章可以幫到你。

技術點

本文不是一個吹噓的文章，不會講很多高深的架構，相反，會講解很多基礎的問題和寫法問題，如果讀者自認為基礎問題和寫法問題都是不是問題，那請忽略這篇文章，節省出時間去做一些有意義的事情。

開發工具

不知道有多少”老”程式設計師還在使用eclipse，這些程式設計師們要不就是因循守舊，要不就是根本就不知道其他好的開發工具的存在，eclipse吃記憶體卡頓的現象以及各種偶然莫名異常的出現，都告知我們是時候尋找新的開發工具了。

更換IDE

根本就不想多解釋要換什麼樣的IDE，如果你想成為一個優秀的java程式設計師，請更換intellij idea. 使用idea的好處，請搜尋谷歌。

別告訴我快捷鍵不好用

更換IDE不在我本文的重點內容中，所以不下想用太多的篇幅去寫為什麼更換IDE，請谷歌。

在這裡，我只能告訴你，更換IDE只為了更好、更快的寫好java程式碼。原因略。

別告訴我快捷鍵不好用，請嘗試新事物。

bean

bean使我們使用最多的模型之一，我將以大篇幅去講解bean，希望讀者好好體會。

domain包名

根據很多java程式設計師的”經驗”來看，一個資料庫表則對應著一個domain物件，所以很多程式設計師在寫程式碼時，包名則使用：com.xxx.domain ，這樣寫好像已經成為了行業的一種約束，資料庫對映物件就應該是domain。但是你錯了，domain是一個領域物件，往往我們再做傳統java軟體web開發中，這些domain都是貧血模型，是沒有行為的，或是沒有足夠的領域模型的行為的，所以，以這個理論來講，這些domain都應該是一個普通的entity物件，並非領域物件，所以請把包名改為:com.xxx.entity。

如果你還不理解我說的話，請看一下Vaughn Vernon出的一本叫做《IMPLEMENTING DOMAIN-DRIVEN DESIGN》(實現領域驅動設計)這本書，書中講解了貧血模型與領域模型的區別，相信你會受益匪淺。

DTO

資料傳輸我們應該使用DTO物件作為傳輸物件，這是我們所約定的，因為很長時間我一直都在做移動端api設計的工作，有很多人告訴我，他們認為只有給手機端傳輸資料的時候(input or output)，這些物件成為DTO物件。請注意！這種理解是錯誤的，只要是用於網路傳輸的物件，我們都認為他們可以當做是DTO物件，比如電商平臺中，使用者進行下單，下單後的資料，訂單會發到OMS 或者 ERP系統，這些對接的返回值以及入參也叫DTO物件。

我們約定某物件如果是DTO物件，就將名稱改為XXDTO,比如訂單下發OMS：OMSOrderInputDTO。

DTO轉化

正如我們所知，DTO為系統與外界互動的模型物件，那麼肯定會有一個步驟是將DTO物件轉化為BO物件或者是普通的entity物件，讓service層去處理。

場景

比如新增會員操作，由於用於演示，我只考慮使用者的一些簡單資料，當後臺管理員點選新增使用者時，只需要傳過來使用者的姓名和年齡就可以了，後端接受到資料後，將新增建立時間和更新時間和預設密碼三個欄位，然後儲存資料庫。

@
RequestMapping
(
"/v1/api/user"
)

@RestController


public 
class 
UserApi 
{



    @Autowired

    
private UserService userService
;



    @PostMapping

    
public User 
addUser
(
UserInputDTO userInputDTO
)
{

        User user 
= 
new 
User
(
)
;

        user
.
setUsername
(userInputDTO
.
getUsername
(
)
)
;

        user
.
setAge
(userInputDTO
.
getAge
(
)
)
;



        
return userService
.
addUser
(user
)
;

    
}


}

我們只關注一下上述程式碼中的轉化程式碼，其他內容請忽略:

User user 
= 
new 
User
(
)
;

user
.
setUsername
(userInputDTO
.
getUsername
(
)
)
;

user
.
setAge
(userInputDTO
.
getAge
(
)
)
;

請使用工具

上邊的程式碼，從邏輯上講，是沒有問題的，只是這種寫法讓我很厭煩，例子中只有兩個欄位，如果有20個欄位，我們要如何做呢？一個一個進行set資料嗎？當然，如果你這麼做了，肯定不會有什麼問題，但是，這肯定不是一個最優的做法。

網上有很多工具，支援淺拷貝或深拷貝的Utils. 舉個例子，我們可以使用org.springframework.beans.BeanUtils#copyProperties對程式碼進行重構和優化:

@PostMapping


public User 
addUser
(
UserInputDTO userInputDTO
)
{

    User user 
= 
new 
User
(
)
;

    BeanUtils
.
copyProperties
(userInputDTO
,user
)
;



    
return userService
.
addUser
(user
)
;


}

BeanUtils.copyProperties是一個淺拷貝方法，複製屬性時，我們只需要把DTO物件和要轉化的物件兩個的屬性值設定為一樣的名稱，並且保證一樣的型別就可以了。如果你在做DTO轉化的時候一直使用set進行屬性賦值，那麼請嘗試這種方式簡化程式碼，讓程式碼更加清晰!

轉化的語義

上邊的轉化過程，讀者看後肯定覺得優雅很多，但是我們再寫java程式碼時，更多的需要考慮語義的操作，再看上邊的程式碼:

User user 
= 
new 
User
(
)
;

BeanUtils
.
copyProperties
(userInputDTO
,user
)
;

雖然這段程式碼很好的簡化和優化了程式碼，但是他的語義是有問題的，我們需要提現一個轉化過程才好,所以程式碼改成如下:

@PostMapping

 
public User 
addUser
(
UserInputDTO userInputDTO
)
{

         User user 
= 
convertFor
(userInputDTO
)
;



         
return userService
.
addUser
(user
)
;

 
}



 
private User 
convertFor
(
UserInputDTO userInputDTO
)
{



         User user 
= 
new 
User
(
)
;

         BeanUtils
.
copyProperties
(userInputDTO
,user
)
;

         
return user
;

 
}

這是一個更好的語義寫法，雖然他麻煩了些，但是可讀性大大增加了，在寫程式碼時，我們應該儘量把語義層次差不多的放到一個方法中，比如:

User user 
= 
convertFor
(userInputDTO
)
;


return userService
.
addUser
(user
)
;

這兩段程式碼都沒有暴露實現，都是在講如何在同一個方法中，做一組相同層次的語義操作，而不是暴露具體的實現。

如上所述，是一種重構方式，讀者可以參考Martin Fowler的《Refactoring Imporving the Design of Existing Code》(重構改善既有程式碼的設計) 這本書中的Extract Method重構方式。

抽象介面定義

當實際工作中，完成了幾個api的DTO轉化時，我們會發現，這樣的操作有很多很多，那麼應該定義好一個介面，讓所有這樣的操作都有規則的進行。如果介面被定義以後，那麼convertFor這個方法的語義將產生變化，他將是一個實現類。

看一下抽象後的介面:


public 
interface 
DTOConvert
<
S
,
T
> 
{

    
T 
convert
(
S s
)
;


}

雖然這個介面很簡單，但是這裡告訴我們一個事情，要去使用泛型，如果你是一個優秀的java程式設計師，請為你想做的抽象介面，做好泛型吧。

我們再來看介面實現:


public 
class 
UserInputDTOConvert 
implements 
DTOConvert
{ 

  @Override 

  
public User 
convert
(
UserInputDTO userInputDTO
) 
{

    User user 
= 
new 
User
(
)
;

    BeanUtils
.
copyProperties
(userInputDTO
,user
)
; 

    
return user
;

  
}


}

我們這樣重構後，我們發現現在的程式碼是如此的簡潔，並且那麼的規範:

@
RequestMapping
(
"/v1/api/user"
)

@RestController


public 
class 
UserApi 
{



    @Autowired

    
private UserService userService
;



    @PostMapping

    
public User 
addUser
(
UserInputDTO userInputDTO
)
{

        User user 
= 
new 
UserInputDTOConvert
(
)
.
convert
(userInputDTO
)
;



        
return userService
.
addUser
(user
)
;

    
}


}

review code

如果你是一個優秀的java程式設計師，我相信你應該和我一樣，已經數次重複review過自己的程式碼很多次了。我們再看這個儲存使用者的例子，你將發現，api中返回值是有些問題的，問題就在於不應該直接返回User實體，因為如果這樣的話，就暴露了太多實體相關的資訊，這樣的返回值是不安全的，所以我們更應該返回一個DTO物件，我們可稱它為UserOutputDTO:

@PostMapping


public UserOutputDTO 
addUser
(
UserInputDTO userInputDTO
)
{

        User user 
= 
new 
UserInputDTOConvert
(
)
.
convert
(userInputDTO
)
;

        User saveUserResult 
= userService
.
addUser
(user
)
;

        UserOutputDTO result 
= 
new 
UserOutDTOConvert
(
)
.
convertToUser
(saveUserResult
)
;

        
return result
;


}

這樣你的api才更健全。

不知道在看完這段程式碼之後，讀者有是否發現還有其他問題的存在，作為一個優秀的java程式設計師，請看一下這段我們剛剛抽象完的程式碼:
User user = new UserInputDTOConvert().convert(userInputDTO);
你會發現，new這樣一個DTO轉化物件是沒有必要的，而且每一個轉化物件都是由在遇到DTO轉化的時候才會出現，那我們應該考慮一下，是否可以將這個類和DTO進行聚合呢，看一下我的聚合結果:
public class UserInputDTO {
private String username;
private int age;


public String 
getUsername
(
) 
{

        
return username
;

    
}



    
public 
void 
setUsername
(
String username
) 
{

        
this
.username 
= username
;

    
}



    
public int 
getAge
(
) 
{

        
return age
;

    
}



    
public 
void 
setAge
(
int age
) 
{

        
this
.age 
= age
;

    
}





    
public User 
convertToUser
(
)
{

        UserInputDTOConvert userInputDTOConvert 
= 
new 
UserInputDTOConvert
(
)
;

        User convert 
= userInputDTOConvert
.
convert
(
this
)
;

        
return convert
;

    
}



    
private 
static 
class 
UserInputDTOConvert 
implements 
DTOConvert
<UserInputDTO
,User
> 
{

        @Override

        
public User 
convert
(
UserInputDTO userInputDTO
) 
{

            User user 
= 
new 
User
(
)
;

            BeanUtils
.
copyProperties
(userInputDTO
,user
)
;

            
return user
;

        
}

    
}




}

然後api中的轉化則由:
User user = new UserInputDTOConvert().convert(userInputDTO);
User saveUserResult = userService.addUser(user);

變成了:
User user = userInputDTO.convertToUser();
User saveUserResult = userService.addUser(user);

我們再DTO物件中新增了轉化的行為，我相信這樣的操作可以讓程式碼的可讀性變得更強，並且是符合語義的。

再查工具類

再來看DTO內部轉化的程式碼，它實現了我們自己定義的DTOConvert介面，但是這樣真的就沒有問題，不需要再思考了嗎？
我覺得並不是，對於Convert這種轉化語義來講，很多工具類中都有這樣的定義，這中Convert並不是業務級別上的介面定義，它只是用於普通bean之間轉化屬性值的普通意義上的介面定義，所以我們應該更多的去讀其他含有Convert轉化語義的程式碼。
我仔細閱讀了一下GUAVA的原始碼，發現了com.google.common.base.Convert這樣的定義:


public abstract 
class 
Converter
<
A
, 
B
> 
implements 
Function
<
A
, 
B
> 
{

    
protected abstract 
B 
doForward
(
A a
)
;

    
protected abstract 
A 
doBackward
(
B b
)
;

    
//其他略


}

從原始碼可以瞭解到，GUAVA中的Convert可以完成正向轉化和逆向轉化，繼續修改我們DTO中轉化的這段程式碼:


private 
static 
class 
UserInputDTOConvert 
implements 
DTOConvert
<UserInputDTO
,User
> 
{

        @Override

        
public User 
convert
(
UserInputDTO userInputDTO
) 
{

                User user 
= 
new 
User
(
)
;

                BeanUtils
.
copyProperties
(userInputDTO
,user
)
;

                
return user
;

        
}


}

修改後:


private 
static 
class 
UserInputDTOConvert 
extends 
Converter
<UserInputDTO
, User
> 
{

         @Override

         
protected User 
doForward
(
UserInputDTO userInputDTO
) 
{

                 User user 
= 
new 
User
(
)
;

                 BeanUtils
.
copyProperties
(userInputDTO
,user
)
;

                 
return user
;

         
}



         @Override

         
protected UserInputDTO 
doBackward
(
User user
) 
{

                 UserInputDTO userInputDTO 
= 
new 
UserInputDTO
(
)
;

                 BeanUtils
.
copyProperties
(user
,userInputDTO
)
;

                 
return userInputDTO
;

         
}

 
}

看了這部分程式碼以後，你可能會問，那逆向轉化會有什麼用呢？其實我們有很多小的業務需求中，入參和出參是一樣的，那麼我們變可以輕鬆的進行轉化，我將上邊所提到的UserInputDTO和UserOutputDTO都轉成UserDTO展示給大家:

DTO：


public 
class 
UserDTO 
{

    
private String username
;

    
private int age
;



    
public String 
getUsername
(
) 
{

            
return username
;

    
}



    
public 
void 
setUsername
(
String username
) 
{

            
this
.username 
= username
;

    
}



    
public int 
getAge
(
) 
{

            
return age
;

    
}



    
public 
void 
setAge
(
int age
) 
{

            
this
.age 
= age
;

    
}

//vx耗:mbz_java_panlong 十年開發經驗程式設計師，免費解答，備註“MI”即可

    
public User 
convertToUser
(
)
{

            UserDTOConvert userDTOConvert 
= 
new 
UserDTOConvert
(
)
;

            User convert 
= userDTOConvert
.
convert
(
this
)
;

            
return convert
;

    
}



    
public UserDTO 
convertFor
(
User user
)
{

            UserDTOConvert userDTOConvert 
= 
new 
UserDTOConvert
(
)
;

            UserDTO convert 
= userDTOConvert
.
reverse
(
)
.
convert
(user
)
;

            
return convert
;

    
}



    
private 
static 
class 
UserDTOConvert 
extends 
Converter
<UserDTO
, User
> 
{

            @Override

            
protected User 
doForward
(
UserDTO userDTO
) 
{

                    User user 
= 
new 
User
(
)
;

                    BeanUtils
.
copyProperties
(userDTO
,user
)
;

                    
return user
;

            
}



            @Override

            
protected UserDTO 
doBackward
(
User user
) 
{

                    UserDTO userDTO 
= 
new 
UserDTO
(
)
;

                    BeanUtils
.
copyProperties
(user
,userDTO
)
;

                    
return userDTO
;

            
}

    
}




}

api:

@PostMapping

 
public UserDTO 
addUser
(
UserDTO userDTO
)
{

         User user 
=  userDTO
.
convertToUser
(
)
;

         User saveResultUser 
= userService
.
addUser
(user
)
;

         UserDTO result 
= userDTO
.
convertFor
(saveResultUser
)
;

         
return result
;

 
}

當然，上述只是表明了轉化方向的正向或逆向，很多業務需求的出參和入參的DTO物件是不同的，那麼你需要更明顯的告訴程式：逆向是無法呼叫的:


private 
static 
class 
UserDTOConvert 
extends 
Converter
<UserDTO
, User
> 
{

         @Override

         
protected User 
doForward
(
UserDTO userDTO
) 
{

                 User user 
= 
new 
User
(
)
;

                 BeanUtils
.
copyProperties
(userDTO
,user
)
;

                 
return user
;

         
}



         @Override

         
protected UserDTO 
doBackward
(
User user
) 
{

                 
throw 
new 
AssertionError
(
"不支援逆向轉化方法!"
)
;

         
}

 
}

看一下doBackward方法，直接丟擲了一個斷言異常，而不是業務異常，這段程式碼告訴程式碼的呼叫者，這個方法不是準你呼叫的，如果你呼叫，我就”斷言”你呼叫錯誤了。

關於異常處理的更詳細介紹，可以參考我之前的文章: 如何優雅的設計java異常，應該可以幫你更好的理解異常。

bean的驗證

如果你認為我上邊寫的那個新增使用者api寫的已經非常完美了，那隻能說明你還不是一個優秀的程式設計師。我們應該保證任何資料的入參到方法體內都是合法的。

為什麼要驗證

很多人會告訴我，如果這些api是提供給前端進行呼叫的，前端都會進行驗證啊，你為什還要驗證？
其實答案是這樣的，我從不相信任何呼叫我api或者方法的人，比如前端驗證失敗了，或者某些人通過一些特殊的渠道(比如Charles進行抓包),直接將資料傳入到我的api，那我仍然進行正常的業務邏輯處理，那麼就有可能產生髒資料！
“對於髒資料的產生一定是致命”，這句話希望大家牢記在心，再小的髒資料也有可能讓你找幾個通宵！

jsr 303驗證

hibernate提供的jsr 303實現，我覺得目前仍然是很優秀的，具體如何使用，我不想講，因為谷歌上你可以搜尋出很多答案!再以上班的api例項進行說明，我們現在對DTO資料進行檢查:


public 
class 
UserDTO 
{

    @NotNull

    
private String username
;

    @NotNull

    
private int age
;

        
//其他程式碼略


}

api驗證:

@PostMapping

    
public UserDTO 
addUser
(
@Valid UserDTO userDTO
)
{

            User user 
=  userDTO
.
convertToUser
(
)
;

            User saveResultUser 
= userService
.
addUser
(user
)
;

            UserDTO result 
= userDTO
.
convertFor
(saveResultUser
)
;

            
return result
;

    
}

我們需要將驗證結果傳給前端，這種異常應該轉化為一個api異常(帶有錯誤碼的異常)。

@PostMapping


public UserDTO 
addUser
(
@Valid UserDTO userDTO
, BindingResult bindingResult
)
{

     
checkDTOParams
(bindingResult
)
;



     User user 
=  userDTO
.
convertToUser
(
)
;

     User saveResultUser 
= userService
.
addUser
(user
)
;

     UserDTO result 
= userDTO
.
convertFor
(saveResultUser
)
;

     
return result
;


}


private 
void 
checkDTOParams
(
BindingResult bindingResult
)
{

     
if
(bindingResult
.
hasErrors
(
)
)
{

             
//throw new 帶驗證碼的驗證錯誤異常

     
}


}

BindingResult是Spring MVC驗證DTO後的一個結果集，可以參考 spring 官方文件

檢查引數後，可以丟擲一個“帶驗證碼的驗證錯誤異常”，具體異常設計可以參考如何優雅的設計java異常

擁抱lombok

上邊的DTO程式碼，已經讓我看的很累了，我相信讀者也是一樣，看到那麼多的Getter和Setter方法，太煩躁了，那時候有什麼方法可以簡化這些呢。請擁抱lombok,它會幫助我們解決一些讓我們很煩躁的問題

去掉Setter和Getter

其實這個標題，我不太想說，因為網上太多，但是因為很多人告訴我，他們根本就不知道lombok的存在，所以為了讓讀者更好的學習，我願意寫這樣一個例子：

@Setter

@Getter


public 
class 
UserDTO 
{

    @NotNull

    
private String username
;

    @NotNull

    
private int age
;



    
public User 
convertToUser
(
)
{

        UserDTOConvert userDTOConvert 
= 
new 
UserDTOConvert
(
)
;

        User convert 
= userDTOConvert
.
convert
(
this
)
;

        
return convert
;

    
}



    
public UserDTO 
convertFor
(
User user
)
{

        UserDTOConvert userDTOConvert 
= 
new 
UserDTOConvert
(
)
;

        UserDTO convert 
= userDTOConvert
.
reverse
(
)
.
convert
(user
)
;

        
return convert
;

    
}



    
private 
static 
class 
UserDTOConvert 
extends 
Converter
<UserDTO
, User
> 
{

        @Override

        
protected User 
doForward
(
UserDTO userDTO
) 
{

            User user 
= 
new 
User
(
)
;

            BeanUtils
.
copyProperties
(userDTO
,user
)
;

            
return user
;

        
}



        @Override

        
protected UserDTO 
doBackward
(
User user
) 
{

            
throw 
new 
AssertionError
(
"不支援逆向轉化方法!"
)
;

        
}

    
}




}

看到了吧，煩人的Getter和Setter方法已經去掉了。
但是上邊的例子根本不足以體現lombok的強大。我希望寫一些網上很難查到，或者很少人進行說明的lombok的使用以及在使用時程式語義上的說明。
比如:@Data,@AllArgsConstructor,@NoArgsConstructor..這些我就不進行一一說明了，請大家自行查詢資料.

bean中的鏈式風格

什麼是鏈式風格？我來舉個例子，看下面這個Student的bean:


public 
class 
Student 
{

    
private String name
;

    
private int age
;



    
public String 
getName
(
) 
{

        
return name
;

    
}



    
public Student 
setName
(
String name
) 
{

        
this
.name 
= name
;

        
return 
this
;

    
}



    
public int 
getAge
(
) 
{

        
return age
;

    
}



    
public Student 
setAge
(
int age
) 
{

        
return 
this
;

    
}


}

仔細看一下set方法，這樣的設定便是chain的style，呼叫的時候，可以這樣使用:

Student student 
= 
new 
Student
(
)

        
.
setAge
(
24
)

        
.
setName
(
"zs"
)
;

相信合理使用這樣的鏈式程式碼，會更多的程式帶來很好的可讀性，那看一下如果使用lombok進行改善呢，請使用 @Accessors(chain = true),看如下程式碼:

@
Accessors
(chain 
= 
true
)

@Setter

@Getter


public 
class 
Student 
{

    
private String name
;

    
private int age
;


}

這樣就完成了一個對於bean來講很友好的鏈式操作。

靜態構造方法

靜態構造方法的語義和簡化程度真的高於直接去new一個物件。比如new一個List物件，過去的使用是這樣的:

List<String> list = new ArrayList<>();

看一下guava中的建立方式:

List<String> list = Lists.newArrayList();

Lists命名是一種約定(俗話說：約定優於配置)，它是指Lists是List這個類的一個工具類，那麼使用List的工具類去產生List，這樣的語義是不是要比直接new一個子類來的更直接一些呢，答案是肯定的，再比如如果有一個工具類叫做Maps，那你是否想到了建立Map的方法呢：

HashMap<String, String> objectObjectHashMap = Maps.newHashMap();

好了，如果你理解了我說的語義，那麼，你已經向成為java程式設計師更近了一步了。

再回過頭來看剛剛的Student，很多時候，我們去寫Student這個bean的時候，他會有一些必輸欄位，比如Student中的name欄位，一般處理的方式是將name欄位包裝成一個構造方法，只有傳入name這樣的構造方法，才能建立一個Student物件。

接上上邊的靜態構造方法和必傳引數的構造方法，使用lombok將更改成如下寫法（@RequiredArgsConstructor 和 @NonNull）:

@
Accessors
(chain 
= 
true
)

@Setter

@Getter

@
RequiredArgsConstructor
(staticName 
= 
"ofName"
)


public 
class 
Student 
{

    @NonNull 
private String name
;

    
private int age
;


}

測試程式碼:

Student student = Student.ofName("zs");

這樣構建出的bean語義是否要比直接new一個含參的構造方法(包含 name的構造方法)要好很多。

當然，看過很多原始碼以後，我想相信將靜態構造方法ofName換成of會先的更加簡潔:

@
Accessors
(chain 
= 
true
)

@Setter

@Getter

@
RequiredArgsConstructor
(staticName 
= 
"of"
)


public 
class 
Student 
{

        @NonNull 
private String name
;

        
private int age
;


}

測試程式碼:

Student student = Student.of("zs");

當然他仍然是支援鏈式呼叫的:

Student student = Student.of("zs").setAge(24);

這樣來寫程式碼，真的很簡潔，並且可讀性很強。

使用builder

Builder模式我不想再多解釋了，讀者可以看一下《Head First》(設計模式) 的建造者模式。

今天其實要說的是一種變種的builder模式，那就是構建bean的builder模式，其實主要的思想是帶著大家一起看一下lombok給我們帶來了什麼。

看一下Student這個類的原始builder狀態:


public 
class 
Student 
{

    
private String name
;

    
private int age
;



    
public String 
getName
(
) 
{

            
return name
;

    
}



    
public 
void 
setName
(
String name
) 
{

            
this
.name 
= name
;

    
}



    
public int 
getAge
(
) 
{

            
return age
;

    
}



    
public 
void 
setAge
(
int age
) 
{

            
this
.age 
= age
;

    
}



    
public 
static Builder 
builder
(
)
{

            
return 
new 
Builder
(
)
;

    
}

    
public 
static 
class 
Builder
{

            
private String name
;

            
private int age
;

            
public Builder 
name
(
String name
)
{

                    
this
.name 
= name
;

                    
return 
this
;

            
}



            
public Builder 
age
(
int age
)
{

                    
this
.age 
= age
;

                    
return 
this
;

            
}



            
public Student 
build
(
)
{

                    Student student 
= 
new 
Student
(
)
;

                    student
.
setAge
(age
)
;

                    student
.
setName
(name
)
;

                    
return student
;

            
}

    
}




}

呼叫方式:

Student student = Student.builder().name("zs").age(24).build();

這樣的builder程式碼，讓我是在噁心難受，於是我打算用lombok重構這段程式碼:

@Builder


public 
class 
Student 
{

    
private String name
;

    
private int age
;


}

呼叫方式:

Student student = Student.builder().name("zs").age(24).build();

代理模式

正如我們所知的，在程式中呼叫rest介面是一個常見的行為動作，如果你和我一樣使用過spring 的RestTemplate,我相信你會我和一樣，對他丟擲的非http狀態碼異常深惡痛絕。

所以我們考慮將RestTemplate最為底層包裝器進行包裝器模式的設計:


public abstract 
class 
FilterRestTemplate 
implements 
RestOperations 
{

        
protected volatile RestTemplate restTemplate
;



        
protected 
FilterRestTemplate
(
RestTemplate restTemplate
)
{

                
this
.restTemplate 
= restTemplate
;

        
}



        
//實現RestOperations所有的介面


}

然後再由擴充套件類對FilterRestTemplate進行包裝擴充套件:


public 
class 
ExtractRestTemplate 
extends 
FilterRestTemplate 
{

    
private RestTemplate restTemplate
;

    
public 
ExtractRestTemplate
(
RestTemplate restTemplate
) 
{

            
super
(restTemplate
)
;

            
this
.restTemplate 
= restTemplate
;

    
}



    
public 
<
T
> RestResponseDTO
<
T
> 
postForEntityWithNoException
(String url
, Object request
, Class
<
T
> responseType
, Object
... uriVariables
)

                    throws RestClientException 
{

            RestResponseDTO
<
T
> restResponseDTO 
= 
new 
RestResponseDTO
<
T
>
(
)
;

            ResponseEntity
<
T
> tResponseEntity
;

            
try 
{

                    tResponseEntity 
= restTemplate
.
postForEntity
(url
, request
, responseType
, uriVariables
)
;

                    restResponseDTO
.
setData
(tResponseEntity
.
getBody
(
)
)
;

                    restResponseDTO
.
setMessage
(tResponseEntity
.
getStatusCode
(
)
.
name
(
)
)
;

                    restResponseDTO
.
setStatusCode
(tResponseEntity
.
getStatusCodeValue
(
)
)
;

            
}
catch 
(Exception e
)
{

                    restResponseDTO
.
setStatusCode
(RestResponseDTO
.
UNKNOWN_ERROR
)
;

                    restResponseDTO
.
setMessage
(e
.
getMessage
(
)
)
;

                    restResponseDTO
.
setData
(
null
)
;

            
}

            
return restResponseDTO
;

    
}


}

包裝器ExtractRestTemplate很完美的更改了異常丟擲的行為，讓程式更具有容錯性。在這裡我們不考慮ExtractRestTemplate完成的功能，讓我們把焦點放在FilterRestTemplate上，“實現RestOperations所有的介面”,這個操作絕對不是一時半會可以寫完的，當時在重構之前我幾乎寫了半個小時,如下:


public abstract 
class 
FilterRestTemplate 
implements 
RestOperations 
{



    
protected volatile RestTemplate restTemplate
;



    
protected 
FilterRestTemplate
(
RestTemplate restTemplate
) 
{

            
this
.restTemplate 
= restTemplate
;

    
}



    @Override

    
public 
<
T
> 
T 
getForObject
(String url
, Class
<
T
> responseType
, Object
... uriVariables
) throws RestClientException 
{

            
return restTemplate
.
getForObject
(url
,responseType
,uriVariables
)
;

    
}



    @Override

    
public 
<
T
> 
T 
getForObject
(String url
, Class
<
T
> responseType
, Map
<String
, 
?
> uriVariables
) throws RestClientException 
{

            
return restTemplate
.
getForObject
(url
,responseType
,uriVariables
)
;

    
}



    @Override

    
public 
<
T
> 
T 
getForObject
(
URI url
, Class
<
T
> responseType
) throws RestClientException 
{

            
return restTemplate
.
getForObject
(url
,responseType
)
;

    
}



    @Override

    
public 
<
T
> ResponseEntity
<
T
> 
getForEntity
(String url
, Class
<
T
> responseType
, Object
... uriVariables
) throws RestClientException 
{

            
return restTemplate
.
getForEntity
(url
,responseType
,uriVariables
)
;

    
}

    
//其他實現程式碼略。。。


}

我相信你看了以上程式碼，你會和我一樣覺得噁心反胃，後來我用lombok提供的代理註解優化了我的程式碼(@Delegate):

@AllArgsConstructor


public abstract 
class 
FilterRestTemplate 
implements 
RestOperations 
{

    @Delegate

    
protected volatile RestTemplate restTemplate
;


}

這幾行程式碼完全替代上述那些冗長的程式碼。是不是很簡潔，做一個擁抱lombok的程式設計師吧。

重構

需求案例

專案需求

專案開發階段，有一個關於下單發貨的需求：如果今天下午3點前進行下單，那麼發貨時間是明天，如果今天下午3點後進行下單，那麼發貨時間是後天，如果被確定的時間是週日，那麼在此時間上再加1天為發貨時間。

思考與重構

我相信這個需求看似很簡單，無論怎麼寫都可以完成。

很多人可能看到這個需求，就動手開始寫Calendar或Date進行計算，從而完成需求。

而我給的建議是，仔細考慮如何寫程式碼，然後再去寫，不是說所有的時間操作都用Calendar或Date去解決，一定要看場景。

對於時間的計算我們要考慮joda-time這種類似的成熟時間計算框架來寫程式碼，它會讓程式碼更加簡潔和易讀。

請讀者先考慮這個需求如何用java程式碼完成，或先寫一個你覺得完成這個程式碼的思路，再來看我下邊的程式碼，這樣，你的收穫會更多一些:

final DateTime 
DISTRIBUTION_TIME_SPLIT_TIME 
= 
new 
DateTime
(
)
.
withTime
(
15
,
0
,
0
,
0
)
;


private Date 
calculateDistributionTimeByOrderCreateTime
(
Date orderCreateTime
)
{

    DateTime orderCreateDateTime 
= 
new 
DateTime
(orderCreateTime
)
;

    Date tomorrow 
= orderCreateDateTime
.
plusDays
(
1
)
.
toDate
(
)
;

    Date theDayAfterTomorrow 
= orderCreateDateTime
.
plusDays
(
2
)
.
toDate
(
)
;

    
return orderCreateDateTime
.
isAfter
(
DISTRIBUTION_TIME_SPLIT_TIME
) 
? 
wrapDistributionTime
(theDayAfterTomorrow
) 
: 
wrapDistributionTime
(tomorrow
)
;


}

//vx耗:mbz_java_panlong 十年開發經驗程式設計師，免費解答，備註“MI”即可


private Date 
wrapDistributionTime
(
Date distributionTime
)
{

    DateTime currentDistributionDateTime 
= 
new 
DateTime
(distributionTime
)
;

    DateTime plusOneDay 
= currentDistributionDateTime
.
plusDays
(
1
)
;

    boolean isSunday 
= 
(DateTimeConstants
.
SUNDAY 
== currentDistributionDateTime
.
getDayOfWeek
(
)
)
;

    
return isSunday 
? plusOneDay
.
toDate
(
) 
: currentDistributionDateTime
.
toDate
(
) 
;


}

讀這段程式碼的時候，你會發現，我將判斷和有可能出現的不同結果都當做一個變數，最終做一個三目運算子的方式進行返回，這樣的優雅和可讀性顯而易見，當然這樣的程式碼不是一蹴而就的，我優化了3遍產生的以上程式碼。讀者可根據自己的程式碼和我寫的程式碼進行對比。

提高方法

如果你做了3年+的程式設計師，我相信像如上這樣的需求，你很輕鬆就能完成，但是如果你想做一個會寫java的程式設計師，就好好的思考和重構程式碼吧。
寫程式碼就如同寫字一樣，同樣的字，大家都會寫，但是寫出來是否好看就不一定了。如果想把程式寫好，就要不斷的思考和重構，敢於嘗試，敢於創新，不要因循守舊，一定要做一個優秀的java程式設計師。
提高程式碼水平最好的方法就是有條理的重構！(注意：是有條理的重構)

設計模式

設計模式就是工具，而不是提現你是否是高水平程式設計師的一個指標。

我經常會看到某一個程式設計師興奮的大喊，哪個程式哪個點我用到了設計模式，寫的多麼多麼優秀，多麼多麼好。我仔細去翻閱的時候，卻發現有很多是過度設計的。

業務驅動技術 or 技術驅動業務

業務驅動技術 or 技術驅動業務？其實這是一個一直在爭論的話題，但是很多人不這麼認為，我覺得就是大家不願意承認罷了。我來和大家大概分析一下作為一個java程式設計師，我們應該如何判斷自己所處於的位置.

業務驅動技術：如果你所在的專案是一個收益很小或者甚至沒有收益的專案，請不要搞其他創新的東西，不要驅動業務要如何如何做，而是要熟知業務現在的痛點是什麼？如何才能幫助業務盈利或者讓專案更好，更順利的進行。

技術驅動業務：如果你所在的專案是一個很牛的專案，比如淘寶這類的專案，我可以在滿足業務需求的情況下，和業務溝通，使用什麼樣的技術能更好的幫助業務創造收益，比如說下單的時候要進佇列，可能幾分鐘之後訂單狀態才能處理完成，但是會讓使用者有更流暢的體驗，賺取更多的訪問流量，那麼我相信業務願意被技術驅動，會同意訂單的延遲問題，這樣便是技術驅動業務。

我相信大部分人還都處於業務驅動技術的方向吧。

所以你既然不能驅動業務，那就請擁抱業務變化吧。

程式碼設計

一直在做java後端的專案，經常會有一些變動，我相信大家也都遇到過。

比如當我們寫一段程式碼的時候，我們考慮將需求對映成程式碼的狀態模式，突然有一天，狀態模式裡邊又新增了很多行為變化的東西，這時候你就撓頭了，你硬生生的將狀態模式中新增過多行為和變化。

慢慢的你會發現這些狀態模式，其實更像是一簇演算法，應該使用策略模式，這時你應該已經暈頭轉向了。

說了這麼多，我的意思是，只要你覺得合理，就請將狀態模式改為策略模式吧，所有的模式並不是憑空想象出來的，都是基於重構。

java程式設計中沒有銀彈，請擁抱業務變化，一直思考重構，你就有一個更好的程式碼設計!

你真的優秀嗎？

真不好意思，我取了一個這麼無聊的標題。

國外流行一種程式設計方式，叫做結對程式設計，我相信國內很多公司都沒有這麼做，我就不在講述結對程式設計帶來的好處了，其實就是一邊code review，一邊互相提高的一個過程。既然做不到這個，那如何讓自己活在自己的世界中不斷提高呢？

“平時開發的時候，做出的程式碼總認為是正確的，而且寫法是完美的。”，我相信這是大部分人的心聲，還回到剛剛的問題，如何在自己的世界中不斷提高呢？

答案就是:

多看成熟框架的原始碼
多回頭看自己的程式碼
勤於重構

你真的優秀嗎？如果你每週都完成了學習原始碼，回頭看自己程式碼，然後勤於重構，我認為你就真的很優秀了。

即使也許你只是剛剛入門，但是一直堅持，你就是一個真的會寫java程式碼的程式設計師了。

技能

UML

不想多討論UML相關的知識，但是我覺得你如果真的會寫java，請先學會表達自己，UML就是你說話的語言，做一名優秀的java程式設計師，請至少學會這兩種UML圖：

類圖
時序圖

clean code

我認為保持程式碼的簡潔和可讀性是程式碼的最基本保證，如果有一天為了程式的效率而降低了這兩點，我認為是可以諒解的，除此之外，沒有任何理由可以讓你任意揮霍你的程式碼。

讀者可以看一下Robert C. Martin出版的《Clean Code》（程式碼整潔之道）這本書
可以參考美團文章聊聊clean code
也可以看一下阿里的 Java編碼規範

無論如何，請保持你的程式碼的整潔。

linux 基礎命令

這點其實和會寫java沒有關係，但是linux很多時候確實承載執行java的容器，請學好linux的基礎命令。

參考鳥哥的《Linux私房菜》

總結

java是一個大體系，今天討論並未涉及框架和架構相關知識，只是討論如何寫好程式碼。

本文從寫java程式的小方面一直寫到大方面，來闡述瞭如何才能寫好java程式，並告訴讀者們如何才能提高自身的編碼水平。

我希望看到這篇文章的各位都能做一個優秀的java程式設計師。

細思極恐 - 你真的會寫 Java 嗎?

導語