亚洲三级影视,天干夜夜爽,中国老太卖婬视频播放,日本一区视频在线观看,日韩黄色电影免费观看,国产精品久久久久一区欢美无码,操美眉影院,A A毛片

點(diǎn)擊上方“碼農(nóng)突圍”，馬上關(guān)注
這里是碼農(nóng)充電第一站，回復(fù)“666”，獲取一份專屬大禮包
真愛，請設(shè)置“星標(biāo)”或點(diǎn)個“在看”

來源：blog.csdn.net/zl1zl2zl3/article/details/85196627

技術(shù)點(diǎn)
開發(fā)工具
Bean
Bean 的驗(yàn)證
擁抱 lombok
重構(gòu)
設(shè)計模式
技能
總結(jié)

技術(shù)點(diǎn)

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

開發(fā)工具

不知道有多少”老”程序員還在使用 Eclipse，這些程序員們要不就是因循守舊，要不就是根本就不知道其他好的開發(fā)工具的存在，Eclipse 吃內(nèi)存卡頓的現(xiàn)象以及各種偶然莫名異常的出現(xiàn)，都告知我們是時候?qū)ふ倚碌拈_發(fā)工具了。

更換 IDE

根本就不想多解釋要換什么樣的 IDE，如果你想成為一個優(yōu)秀的 Java 程序員，請更換 IntelliJ IDEA。使用 IDEA 的好處，請搜索谷歌。

別告訴我快捷鍵不好用

更換 IDE 不在我本文的重點(diǎn)內(nèi)容中，所以不想用太多的篇幅去寫為什么更換IDE。在這里，我只能告訴你，更換 IDE 只為了更好、更快的寫好 Java 代碼。原因略。

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

Bean

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

domain 包名

根據(jù)很多 Java 程序員的”經(jīng)驗(yàn)”來看，一個數(shù)據(jù)庫表則對應(yīng)著一個 domain 對象，所以很多程序員在寫代碼時，包名則使用：com.xxx.domain ，這樣寫好像已經(jīng)成為了行業(yè)的一種約束，數(shù)據(jù)庫映射對象就應(yīng)該是 domain。但是你錯了，domain 是一個領(lǐng)域?qū)ο螅覀冊僮鰝鹘y(tǒng) Java 軟件 Web 開發(fā)中，這些 domain 都是貧血模型，是沒有行為的，或是沒有足夠的領(lǐng)域模型的行為的，所以，以這個理論來講，這些 domain 都應(yīng)該是一個普通的 entity 對象，并非領(lǐng)域?qū)ο螅哉埌寻臑?com.xxx.entity。

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

DTO

數(shù)據(jù)傳輸我們應(yīng)該使用 DTO 對象作為傳輸對象，這是我們所約定的，因?yàn)楹荛L時間我一直都在做移動端 API 設(shè)計的工作，有很多人告訴我，他們認(rèn)為只有給手機(jī)端傳輸數(shù)據(jù)的時候(input or output)，這些對象成為 DTO 對象。請注意！這種理解是錯誤的，只要是用于網(wǎng)絡(luò)傳輸?shù)膶ο螅覀兌颊J(rèn)為他們可以當(dāng)做是 DTO 對象，比如電商平臺中，用戶進(jìn)行下單，下單后的數(shù)據(jù)，訂單會發(fā)到 OMS 或者 ERP 系統(tǒng)，這些對接的返回值以及入?yún)⒁步?DTO 對象。

我們約定某對象如果是 DTO 對象，就將名稱改為 XXDTO，比如訂單下發(fā)OMS：OMSOrderInputDTO。

DTO 轉(zhuǎn)化

正如我們所知，DTO 為系統(tǒng)與外界交互的模型對象，那么肯定會有一個步驟是將 DTO 對象轉(zhuǎn)化為 BO 對象或者是普通的 entity 對象，讓 service 層去處理。

場景

比如添加會員操作，由于用于演示，我只考慮用戶的一些簡單數(shù)據(jù)，當(dāng)后臺管理員點(diǎn)擊添加用戶時，只需要傳過來用戶的姓名和年齡就可以了，后端接受到數(shù)據(jù)后，將添加創(chuàng)建時間和更新時間和默認(rèn)密碼三個字段，然后保存數(shù)據(jù)庫。

@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);
????}
}

我們只關(guān)注一下上述代碼中的轉(zhuǎn)化代碼，其他內(nèi)容請忽略：

User?user?=?new?User();
user.setUsername(userInputDTO.getUsername());
user.setAge(userInputDTO.getAge());

請使用工具

上邊的代碼，從邏輯上講，是沒有問題的，只是這種寫法讓我很厭煩，例子中只有兩個字段，如果有 20 個字段，我們要如何做呢？一個一個進(jìn)行 set 數(shù)據(jù)嗎？當(dāng)然，如果你這么做了，肯定不會有什么問題，但是，這肯定不是一個最優(yōu)的做法。

網(wǎng)上有很多工具，支持淺拷貝或深拷貝的 Utils。舉個例子，我們可以使用 org.springframework.beans.BeanUtils#copyProperties 對代碼進(jìn)行重構(gòu)和優(yōu)化：

@PostMapping
public?User?addUser(UserInputDTO?userInputDTO){
????User?user?=?new?User();
????BeanUtils.copyProperties(userInputDTO,user);

????return?userService.addUser(user);
}

BeanUtils.copyProperties 是一個淺拷貝方法，復(fù)制屬性時，我們只需要把 DTO 對象和要轉(zhuǎn)化的對象兩個的屬性值設(shè)置為一樣的名稱，并且保證一樣的類型就可以了。如果你在做 DTO 轉(zhuǎn)化的時候一直使用 set 進(jìn)行屬性賦值，那么請嘗試這種方式簡化代碼，讓代碼更加清晰!

轉(zhuǎn)化的語義

上邊的轉(zhuǎn)化過程，讀者看后肯定覺得優(yōu)雅很多，但是我們再寫 Java 代碼時，更多的需要考慮語義的操作，再看上邊的代碼：

User?user?=?new?User();
BeanUtils.copyProperties(userInputDTO,user);

雖然這段代碼很好的簡化和優(yōu)化了代碼，但是他的語義是有問題的，我們需要提現(xiàn)一個轉(zhuǎn)化過程才好，所以代碼改成如下：

@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;
?}

這是一個更好的語義寫法，雖然他麻煩了些，但是可讀性大大增加了，在寫代碼時，我們應(yīng)該盡量把語義層次差不多的放到一個方法中，比如：

User?user?=?convertFor(userInputDTO);
return?userService.addUser(user);

這兩段代碼都沒有暴露實(shí)現(xiàn)，都是在講如何在同一個方法中，做一組相同層次的語義操作，而不是暴露具體的實(shí)現(xiàn)。

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

抽象接口定義

當(dāng)實(shí)際工作中，完成了幾個 API 的 DTO 轉(zhuǎn)化時，我們會發(fā)現(xiàn)，這樣的操作有很多很多，那么應(yīng)該定義好一個接口，讓所有這樣的操作都有規(guī)則的進(jìn)行。

如果接口被定義以后，那么 convertFor 這個方法的語義將產(chǎn)生變化，它將是一個實(shí)現(xiàn)類。

看一下抽象后的接口：

public?interface?DTOConvert?{
????T?convert(S?s);
}

雖然這個接口很簡單，但是這里告訴我們一個事情，要去使用泛型，如果你是一個優(yōu)秀的 Java 程序員，請為你想做的抽象接口，做好泛型吧。

我們再來看接口實(shí)現(xiàn)：

public?class?UserInputDTOConvert?implements?DTOConvert?{
@Override
public?User?convert(UserInputDTO?userInputDTO)?{
User?user?=?new?User();
BeanUtils.copyProperties(userInputDTO,user);
return?user;
}
}

我們這樣重構(gòu)后，我們發(fā)現(xiàn)現(xiàn)在的代碼是如此的簡潔，并且那么的規(guī)范：

@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

如果你是一個優(yōu)秀的 Java 程序員，我相信你應(yīng)該和我一樣，已經(jīng)數(shù)次重復(fù) review 過自己的代碼很多次了。

我們再看這個保存用戶的例子，你將發(fā)現(xiàn)，API 中返回值是有些問題的，問題就在于不應(yīng)該直接返回 User 實(shí)體，因?yàn)槿绻@樣的話，就暴露了太多實(shí)體相關(guān)的信息，這樣的返回值是不安全的，所以我們更應(yīng)該返回一個 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 才更健全。

不知道在看完這段代碼之后，讀者有是否發(fā)現(xiàn)還有其他問題的存在，作為一個優(yōu)秀的 Java 程序員，請看一下這段我們剛剛抽象完的代碼:

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

你會發(fā)現(xiàn)，new 這樣一個 DTO 轉(zhuǎn)化對象是沒有必要的，而且每一個轉(zhuǎn)化對象都是由在遇到 DTO 轉(zhuǎn)化的時候才會出現(xiàn)，那我們應(yīng)該考慮一下，是否可以將這個類和 DTO 進(jìn)行聚合呢，看一下我的聚合結(jié)果:

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?{
????????@Override
????????public?User?convert(UserInputDTO?userInputDTO)?{
????????????User?user?=?new?User();
????????????BeanUtils.copyProperties(userInputDTO,user);
????????????return?user;
????????}
????}

}

然后 API 中的轉(zhuǎn)化則由：

User?user?=?new?UserInputDTOConvert().convert(userInputDTO);
User?saveUserResult?=?userService.addUser(user);

變成了：

User?user?=?userInputDTO.convertToUser();
User?saveUserResult?=?userService.addUser(user);

我們再 DTO 對象中添加了轉(zhuǎn)化的行為，我相信這樣的操作可以讓代碼的可讀性變得更強(qiáng)，并且是符合語義的。

再查工具類

再來看 DTO 內(nèi)部轉(zhuǎn)化的代碼，它實(shí)現(xiàn)了我們自己定義的 DTOConvert 接口，但是這樣真的就沒有問題，不需要再思考了嗎？

我覺得并不是，對于 Convert 這種轉(zhuǎn)化語義來講，很多工具類中都有這樣的定義，這中 Convert 并不是業(yè)務(wù)級別上的接口定義，它只是用于普通 bean 之間轉(zhuǎn)化屬性值的普通意義上的接口定義，所以我們應(yīng)該更多的去讀其他含有 Convert 轉(zhuǎn)化語義的代碼。

我仔細(xì)閱讀了一下 GUAVA 的源碼，發(fā)現(xiàn)了 com.google.common.base.Convert 這樣的定義：

public?abstract?class?Converter?implements?Function?{
????protected?abstract?B?doForward(A?a);
????protected?abstract?A?doBackward(B?b);
????//其他略
}

從源碼可以了解到，GUAVA 中的 Convert 可以完成正向轉(zhuǎn)化和逆向轉(zhuǎn)化，繼續(xù)修改我們 DTO 中轉(zhuǎn)化的這段代碼：

private?static?class?UserInputDTOConvert?implements?DTOConvert?{
????????@Override
????????public?User?convert(UserInputDTO?userInputDTO)?{
????????????????User?user?=?new?User();
????????????????BeanUtils.copyProperties(userInputDTO,user);
????????????????return?user;
????????}
}

修改后：

private?static?class?UserInputDTOConvert?extends?Converter?{
?????????@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;
?????????}
?}

看了這部分代碼以后，你可能會問，那逆向轉(zhuǎn)化會有什么用呢？其實(shí)我們有很多小的業(yè)務(wù)需求中，入?yún)⒑统鰠⑹且粯拥模敲次覀冏兛梢暂p松的進(jìn)行轉(zhuǎn)化，我將上邊所提到的 UserInputDTO 和 UserOutputDTO 都轉(zhuǎn)成 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;
????}


????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?{
????????????@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;
?}

當(dāng)然，上述只是表明了轉(zhuǎn)化方向的正向或逆向，很多業(yè)務(wù)需求的出參和入?yún)⒌?DTO 對象是不同的，那么你需要更明顯的告訴程序：逆向是無法調(diào)用的：

private?static?class?UserDTOConvert?extends?Converter?{
?????????@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("不支持逆向轉(zhuǎn)化方法!");
?????????}
?}

看一下 doBackward 方法，直接拋出了一個斷言異常，而不是業(yè)務(wù)異常，這段代碼告訴代碼的調(diào)用者，這個方法不是準(zhǔn)你調(diào)用的，如果你調(diào)用，我就”斷言”你調(diào)用錯誤了。

關(guān)于異常處理的更詳細(xì)介紹，可以參考我之前的文章：如何優(yōu)雅的設(shè)計 Java 異常（http://lrwinx.github.io/2016/04/28/%E5%A6%82%E4%BD%95%E4%BC%98%E9%9B%85%E7%9A%84%E8%AE%BE%E8%AE%A1java%E5%BC%82%E5%B8%B8/），應(yīng)該可以幫你更好的理解異常。

Bean 的驗(yàn)證

如果你認(rèn)為我上邊寫的那個添加用戶 API 寫的已經(jīng)非常完美了，那只能說明你還不是一個優(yōu)秀的程序員。我們應(yīng)該保證任何數(shù)據(jù)的入?yún)⒌椒椒w內(nèi)都是合法的。

為什么要驗(yàn)證

很多人會告訴我，如果這些 API 是提供給前端進(jìn)行調(diào)用的，前端都會進(jìn)行驗(yàn)證啊，你為什還要驗(yàn)證？

其實(shí)答案是這樣的，我從不相信任何調(diào)用我 API 或者方法的人，比如前端驗(yàn)證失敗了，或者某些人通過一些特殊的渠道(比如 Charles 進(jìn)行抓包)，直接將數(shù)據(jù)傳入到我的 API，那我仍然進(jìn)行正常的業(yè)務(wù)邏輯處理，那么就有可能產(chǎn)生臟數(shù)據(jù)！

“對于臟數(shù)據(jù)的產(chǎn)生一定是致命”，這句話希望大家牢記在心，再小的臟數(shù)據(jù)也有可能讓你找?guī)讉€通宵！

jsr 303驗(yàn)證

hibernate 提供的 jsr 303 實(shí)現(xiàn)，我覺得目前仍然是很優(yōu)秀的，具體如何使用，我不想講，因?yàn)楣雀枭夏憧梢运阉鞒龊芏啻鸢?

再以上班的 API 實(shí)例進(jìn)行說明，我們現(xiàn)在對 DTO 數(shù)據(jù)進(jìn)行檢查：

public?class?UserDTO?{
????@NotNull
????private?String?username;
????@NotNull
????private?int?age;
????????//其他代碼略
}

API 驗(yàn)證：

@PostMapping
????public?UserDTO?addUser(@Valid?UserDTO?userDTO){
????????????User?user?=??userDTO.convertToUser();
????????????User?saveResultUser?=?userService.addUser(user);
????????????UserDTO?result?=?userDTO.convertFor(saveResultUser);
????????????return?result;
????}

我們需要將驗(yàn)證結(jié)果傳給前端，這種異常應(yīng)該轉(zhuǎn)化為一個 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?帶驗(yàn)證碼的驗(yàn)證錯誤異常
?????}
}

BindingResult 是 Spring MVC 驗(yàn)證 DTO 后的一個結(jié)果集，可以參考spring 官方文檔（http://spring.io/）。

檢查參數(shù)后，可以拋出一個“帶驗(yàn)證碼的驗(yàn)證錯誤異常”，具體異常設(shè)計可以參考如何優(yōu)雅的設(shè)計 Java 異常（http://lrwinx.github.io/2016/04/28/%E5%A6%82%E4%BD%95%E4%BC%98%E9%9B%85%E7%9A%84%E8%AE%BE%E8%AE%A1java%E5%BC%82%E5%B8%B8/）。

擁抱 lombok

上邊的 DTO 代碼，已經(jīng)讓我看的很累了，我相信讀者也是一樣，看到那么多的 Getter 和 Setter 方法，太煩躁了，那時候有什么方法可以簡化這些呢。

請擁抱 lombok,它會幫助我們解決一些讓我們很煩躁的問題

去掉 Setter 和 Getter

其實(shí)這個標(biāo)題，我不太想說，因?yàn)榫W(wǎng)上太多，但是因?yàn)楹芏嗳烁嬖V我，他們根本就不知道 lombok 的存在，所以為了讓讀者更好的學(xué)習(xí)，我愿意寫這樣一個例子：

@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?{
????????@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("不支持逆向轉(zhuǎn)化方法!");
????????}
????}

}

看到了吧，煩人的 Getter 和 Setter 方法已經(jīng)去掉了。

但是上邊的例子根本不足以體現(xiàn) lombok 的強(qiáng)大。我希望寫一些網(wǎng)上很難查到，或者很少人進(jìn)行說明的 lombok 的使用以及在使用時程序語義上的說明。

比如:@Data,@AllArgsConstructor,@NoArgsConstructor..這些我就不進(jìn)行一一說明了，請大家自行查詢資料。

bean 中的鏈?zhǔn)斤L(fēng)格

什么是鏈?zhǔn)斤L(fēng)格？我來舉個例子，看下面這個 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;
????}
}

仔細(xì)看一下 set 方法，這樣的設(shè)置便是 chain 的 style，調(diào)用的時候，可以這樣使用：

Student?student?=?new?Student()
????????.setAge(24)
????????.setName("zs");

相信合理使用這樣的鏈?zhǔn)酱a，會更多的程序帶來很好的可讀性，那看一下如果使用 lombok 進(jìn)行改善呢，請使用 @Accessors(chain = true)，看如下代碼：

@Accessors(chain?=?true)
@Setter
@Getter
public?class?Student?{
????private?String?name;
????private?int?age;
}

這樣就完成了一個對于 bean 來講很友好的鏈?zhǔn)讲僮鳌?/section>

靜態(tài)構(gòu)造方法

靜態(tài)構(gòu)造方法的語義和簡化程度真的高于直接去 new 一個對象。比如 new 一個 List 對象，過去的使用是這樣的：

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

看一下 guava 中的創(chuàng)建方式：

List?list?=?Lists.newArrayList();

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

HashMap?objectObjectHashMap?=?Maps.newHashMap();

好了，如果你理解了我說的語義，那么，你已經(jīng)向成為 Java 程序員更近了一步了。

再回過頭來看剛剛的 Student，很多時候，我們?nèi)?Student 這個 bean 的時候，他會有一些必輸字段，比如 Student 中的 name 字段，一般處理的方式是將 name 字段包裝成一個構(gòu)造方法，只有傳入 name 這樣的構(gòu)造方法，才能創(chuàng)建一個 Student 對象。

接上上邊的靜態(tài)構(gòu)造方法和必傳參數(shù)的構(gòu)造方法，使用 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");

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

當(dāng)然，看過很多源碼以后，我想相信將靜態(tài)構(gòu)造方法 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");

當(dāng)然他仍然是支持鏈?zhǔn)秸{(diào)用的：

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

這樣來寫代碼，真的很簡潔，并且可讀性很強(qiáng)。

使用 builder

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

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

看一下 Student 這個類的原始 builder 狀態(tài):

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;
????????????}
????}

}

調(diào)用方式：

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

這樣的 builder 代碼，讓我是在惡心難受，于是我打算用 lombok 重構(gòu)這段代碼：

@Builder
public?class?Student?{
????private?String?name;
????private?int?age;
}

調(diào)用方式：

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

代理模式

正如我們所知的，在程序中調(diào)用 rest 接口是一個常見的行為動作，如果你和我一樣使用過 spring 的 RestTemplate，我相信你會我和一樣，對他拋出的非 http 狀態(tài)碼異常深惡痛絕。

所以我們考慮將 RestTemplate 最為底層包裝器進(jìn)行包裝器模式的設(shè)計：

public?abstract?class?FilterRestTemplate?implements?RestOperations?{
????????protected?volatile?RestTemplate?restTemplate;

????????protected?FilterRestTemplate(RestTemplate?restTemplate){
????????????????this.restTemplate?=?restTemplate;
????????}

????????//實(shí)現(xiàn)RestOperations所有的接口
}

然后再由擴(kuò)展類對 FilterRestTemplate 進(jìn)行包裝擴(kuò)展：

public?class?ExtractRestTemplate?extends?FilterRestTemplate?{
????private?RestTemplate?restTemplate;
????public?ExtractRestTemplate(RestTemplate?restTemplate)?{
????????????super(restTemplate);
????????????this.restTemplate?=?restTemplate;
????}

????public??RestResponseDTO?postForEntityWithNoException(String?url,?Object?request,?Class?responseType,?Object...?uriVariables)
????????????????????throws?RestClientException?{
????????????RestResponseDTO?restResponseDTO?=?new?RestResponseDTO();
????????????ResponseEntity?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 完成的功能，讓我們把焦點(diǎn)放在 FilterRestTemplate 上，“實(shí)現(xiàn) RestOperations 所有的接口”,這個操作絕對不是一時半會可以寫完的，當(dāng)時在重構(gòu)之前我?guī)缀鯇懥税雮€小時,如下：

public?abstract?class?FilterRestTemplate?implements?RestOperations?{

????protected?volatile?RestTemplate?restTemplate;

????protected?FilterRestTemplate(RestTemplate?restTemplate)?{
????????????this.restTemplate?=?restTemplate;
????}

????@Override
????public??T?getForObject(String?url,?Class?responseType,?Object...?uriVariables)?throws?RestClientException?{
????????????return?restTemplate.getForObject(url,responseType,uriVariables);
????}

????@Override
????public??T?getForObject(String?url,?Class?responseType,?Map?uriVariables)?throws?RestClientException?{
????????????return?restTemplate.getForObject(url,responseType,uriVariables);
????}

????@Override
????public??T?getForObject(URI?url,?Class?responseType)?throws?RestClientException?{
????????????return?restTemplate.getForObject(url,responseType);
????}

????@Override
????public??ResponseEntity?getForEntity(String?url,?Class?responseType,?Object...?uriVariables)?throws?RestClientException?{
????????????return?restTemplate.getForEntity(url,responseType,uriVariables);
????}
????//其他實(shí)現(xiàn)代碼略。。。
}

我相信你看了以上代碼，你會和我一樣覺得惡心反胃，后來我用 lombok 提供的代理注解優(yōu)化了我的代碼(@Delegate)：

@AllArgsConstructor
public?abstract?class?FilterRestTemplate?implements?RestOperations?{
????@Delegate
????protected?volatile?RestTemplate?restTemplate;
}

這幾行代碼完全替代上述那些冗長的代碼。

是不是很簡潔，做一個擁抱 lombok 的程序員吧。

重構(gòu)

需求案例

項目需求

項目開發(fā)階段，有一個關(guān)于下單發(fā)貨的需求：如果今天下午 3 點(diǎn)前進(jìn)行下單，那么發(fā)貨時間是明天，如果今天下午 3 點(diǎn)后進(jìn)行下單，那么發(fā)貨時間是后天，如果被確定的時間是周日，那么在此時間上再加 1 天為發(fā)貨時間。

思考與重構(gòu)

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

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

而我給的建議是，仔細(xì)考慮如何寫代碼，然后再去寫，不是說所有的時間操作都用 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);
}
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()?;
}

讀這段代碼的時候，你會發(fā)現(xiàn)，我將判斷和有可能出現(xiàn)的不同結(jié)果都當(dāng)做一個變量，最終做一個三目運(yùn)算符的方式進(jìn)行返回，這樣的優(yōu)雅和可讀性顯而易見，當(dāng)然這樣的代碼不是一蹴而就的，我優(yōu)化了 3 遍產(chǎn)生的以上代碼。讀者可根據(jù)自己的代碼和我寫的代碼進(jìn)行對比。

提高方法

如果你做了 3 年+的程序員，我相信像如上這樣的需求，你很輕松就能完成，但是如果你想做一個會寫 Java 的程序員，就好好的思考和重構(gòu)代碼吧。

寫代碼就如同寫字一樣，同樣的字，大家都會寫，但是寫出來是否好看就不一定了。如果想把程序?qū)懞茫鸵粩嗟乃伎己椭貥?gòu)，敢于嘗試，敢于創(chuàng)新，不要因循守舊，一定要做一個優(yōu)秀的 Java 程序員。

提高代碼水平最好的方法就是有條理的重構(gòu)！(注意：是有條理的重構(gòu))

設(shè)計模式

設(shè)計模式就是工具，而不是提現(xiàn)你是否是高水平程序員的一個指標(biāo)。

我經(jīng)常會看到某一個程序員興奮的大喊，哪個程序哪個點(diǎn)我用到了設(shè)計模式，寫的多么多么優(yōu)秀，多么多么好。我仔細(xì)去翻閱的時候，卻發(fā)現(xiàn)有很多是過度設(shè)計的。

業(yè)務(wù)驅(qū)動技術(shù) or 技術(shù)驅(qū)動業(yè)務(wù)

業(yè)務(wù)驅(qū)動技術(shù) or 技術(shù)驅(qū)動業(yè)務(wù) ？其實(shí)這是一個一直在爭論的話題，但是很多人不這么認(rèn)為，我覺得就是大家不愿意承認(rèn)罷了。我來和大家大概分析一下作為一個 Java 程序員，我們應(yīng)該如何判斷自己所處于的位置.

業(yè)務(wù)驅(qū)動技術(shù)： 如果你所在的項目是一個收益很小或者甚至沒有收益的項目，請不要搞其他創(chuàng)新的東西，不要驅(qū)動業(yè)務(wù)要如何如何做，而是要熟知業(yè)務(wù)現(xiàn)在的痛點(diǎn)是什么？如何才能幫助業(yè)務(wù)盈利或者讓項目更好，更順利的進(jìn)行。

技術(shù)驅(qū)動業(yè)務(wù)： 如果你所在的項目是一個很牛的項目，比如淘寶這類的項目，我可以在滿足業(yè)務(wù)需求的情況下，和業(yè)務(wù)溝通，使用什么樣的技術(shù)能更好的幫助業(yè)務(wù)創(chuàng)造收益，比如說下單的時候要進(jìn)隊列，可能幾分鐘之后訂單狀態(tài)才能處理完成，但是會讓用戶有更流暢的體驗(yàn)，賺取更多的訪問流量，那么我相信業(yè)務(wù)愿意被技術(shù)驅(qū)動，會同意訂單的延遲問題，這樣便是技術(shù)驅(qū)動業(yè)務(wù)。

我相信大部分人還都處于業(yè)務(wù)驅(qū)動技術(shù)的方向吧。

所以你既然不能驅(qū)動業(yè)務(wù)，那就請擁抱業(yè)務(wù)變化吧。

代碼設(shè)計

一直在做 Java 后端的項目，經(jīng)常會有一些變動，我相信大家也都遇到過。

比如當(dāng)我們寫一段代碼的時候，我們考慮將需求映射成代碼的狀態(tài)模式，突然有一天，狀態(tài)模式里邊又添加了很多行為變化的東西，這時候你就撓頭了，你硬生生的將狀態(tài)模式中添加過多行為和變化。

慢慢的你會發(fā)現(xiàn)這些狀態(tài)模式，其實(shí)更像是一簇算法，應(yīng)該使用策略模式，這時你應(yīng)該已經(jīng)暈頭轉(zhuǎn)向了。

說了這么多，我的意思是，只要你覺得合理，就請將狀態(tài)模式改為策略模式吧，所有的模式并不是憑空想象出來的，都是基于重構(gòu)。

Java 編程中沒有銀彈，請擁抱業(yè)務(wù)變化，一直思考重構(gòu)，你就有一個更好的代碼設(shè)計!

你真的優(yōu)秀嗎？

真不好意思，我取了一個這么無聊的標(biāo)題。

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

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

答案就是:

多看成熟框架的源碼
多回頭看自己的代碼
勤于重構(gòu)

你真的優(yōu)秀嗎？如果你每周都完成了學(xué)習(xí)源碼，回頭看自己代碼，然后勤于重構(gòu)，我認(rèn)為你就真的很優(yōu)秀了。

即使也許你只是剛剛?cè)腴T，但是一直堅持，你就是一個真的會寫java代碼的程序員了。

技能

UML

不想多討論 UML 相關(guān)的知識，但是我覺得你如果真的會寫 Java，請先學(xué)會表達(dá)自己，UML 就是你說話的語言，做一名優(yōu)秀的 Java 程序員，請至少學(xué)會這兩種 UML 圖：

類圖
時序圖

clean code

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

讀者可以看一下 Robert C. Martin 出版的《Clean Code》（代碼整潔之道）這本書
可以參考美團(tuán)文章聊聊 clean code（http://tech.meituan.com/clean-code.html）；
也可以看一下阿里的 Java 編碼規(guī)范（https://yq.aliyun.com/articles/69327?spm=5176.100239.topwz.1.om5dRN）。

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

Linux 基礎(chǔ)命令

這點(diǎn)其實(shí)和會寫 Java 沒有關(guān)系，但是 Linux 很多時候確實(shí)承載運(yùn)行 Java 的容器，請學(xué)好 Linux 的基礎(chǔ)命令。

參考鳥哥的《Linux私房菜》

總結(jié)

Java 是一個大體系，今天討論并未涉及框架和架構(gòu)相關(guān)知識，只是討論如何寫好代碼。

本文從寫 Java 程序的小方面一直寫到大方面，來闡述了如何才能寫好 Java 程序，并告訴讀者們?nèi)绾尾拍芴岣咦陨淼木幋a水平。

我希望看到這篇文章的各位都能做一個優(yōu)秀的 Java 程序員。

（完）
碼農(nóng)突圍資料鏈接
1、臥槽！字節(jié)跳動《算法中文手冊》火了，完整版 PDF 開放下載！
2、計算機(jī)基礎(chǔ)知識總結(jié)與操作系統(tǒng) PDF 下載
3、艾瑪，終于來了！《LeetCode Java版題解》.PDF
4、Github 10K+，《LeetCode刷題C/C++版答案》出爐.PDF
歡迎添加魚哥個人微信：smartfish2020，進(jìn)粉絲群或圍觀朋友圈

你見過哪些目瞪口呆的 Java 代碼技巧？