欢乐颂小说结局是什么,盗墓笔记同人小说

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

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

導(dǎo)語

從出來，本人一直在做 Java 相關(guān)的工作，現(xiàn)在終于有時(shí)間坐下來，寫一篇關(guān)于 Java 寫法的一篇文章，來探討一下如果你真的是一個(gè) Java 程序員，那你真的會寫 Java 嗎？

筆者是一個(gè)務(wù)實(shí)的程序員，故本文絕非扯淡文章，文中內(nèi)容都是干貨，望讀者看后，能有所收獲。

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

開發(fā)工具

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

更換 IDE

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

別告訴我快捷鍵不好用

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

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

bean

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

domain 包名

根據(jù)很多 Java 程序員的“經(jīng)驗(yàn)”來看，一個(gè)數(shù)據(jù)庫表則對應(yīng)著一個(gè) domain 對象，所以很多程序員在寫代碼時(shí)，包名則使用：com.xxx.domain ，這樣寫好像已經(jīng)成為了行業(yè)的一種約束，數(shù)據(jù)庫映射對象就應(yīng)該是 domain。

但是你錯(cuò)了，domain 是一個(gè)領(lǐng)域?qū)ο?，往往我們再做傳統(tǒng) Java 軟件 Web 開發(fā)中，這些 domain 都是貧血模型，是沒有行為的，或是沒有足夠的領(lǐng)域模型的行為的。

所以，以這個(gè)理論來講，這些 domain 都應(yīng)該是一個(gè)普通的 entity 對象，并非領(lǐng)域?qū)ο?，所以請把包名改為：com.xxx.entity。

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

DTO

數(shù)據(jù)傳輸我們應(yīng)該使用 DTO 對象作為傳輸對象，這是我們所約定的，因?yàn)楹荛L時(shí)間我一直都在做移動端 API 設(shè)計(jì)的工作，有很多人告訴我，他們認(rèn)為只有給手機(jī)端傳輸數(shù)據(jù)的時(shí)候（input or output），這些對象成為 DTO 對象。

請注意！這種理解是錯(cuò)誤的，只要是用于網(wǎng)絡(luò)傳輸?shù)膶ο?，我們都認(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)與外界交互的模型對象，那么肯定會有一個(gè)步驟是將 DTO 對象轉(zhuǎn)化為 BO 對象或者是普通的 entity 對象，讓 service 層去處理。

場景

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

請使用工具

上邊的代碼，從邏輯上講，是沒有問題的，只是這種寫法讓我很厭煩，例子中只有兩個(gè)字段，如果有 20 個(gè)字段，我們要如何做呢？一個(gè)一個(gè)進(jìn)行 set 數(shù)據(jù)嗎？

當(dāng)然，如果你這么做了，肯定不會有什么問題，但是，這肯定不是一個(gè)最優(yōu)的做法。網(wǎng)上有很多工具，支持淺拷貝或深拷貝的 Utils。

舉個(gè)例子，我們可以使用 org.springframework.beans.BeanUtils#copyProperties 對代碼進(jìn)行重構(gòu)和優(yōu)化：

BeanUtils.copyProperties 是一個(gè)淺拷貝方法，復(fù)制屬性時(shí)，我們只需要把 DTO 對象和要轉(zhuǎn)化的對象兩個(gè)的屬性值設(shè)置為一樣的名稱，并且保證一樣的類型就可以了。

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

如果你在做 DTO 轉(zhuǎn)化的時(shí)候一直使用 set 進(jìn)行屬性賦值，那么請嘗試這種方式簡化代碼，讓代碼更加清晰！

轉(zhuǎn)化的語義

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

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

雖然這段代碼很好的簡化和優(yōu)化了代碼，但是他的語義是有問題的，我們需要提現(xiàn)一個(gè)轉(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;
}

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

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

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

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

抽象接口定義

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

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

看一下抽象后的接口：

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

雖然這個(gè)接口很簡單，但是這里告訴我們一個(gè)事情，要去使用泛型，如果你是一個(gè)優(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

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

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

所以我們更應(yīng)該返回一個(gè) 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)還有其他問題的存在，作為一個(gè)優(yōu)秀的 Java 程序員，請看一下這段我們剛剛抽象完的代碼：

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

你會發(fā)現(xiàn)，new 這樣一個(gè) DTO 轉(zhuǎn)化對象是沒有必要的，而且每一個(gè)轉(zhuǎn)化對象都是由在遇到 DTO 轉(zhuǎn)化的時(shí)候才會出現(xiàn)，那我們應(yīng)該考慮一下，是否可以將這個(gè)類和 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)⒑统鰠⑹且粯拥?，那么我們變可以輕松的進(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 方法，直接拋出了一個(gè)斷言異常，而不是業(yè)務(wù)異常，這段代碼告訴代碼的調(diào)用者，這個(gè)方法不是準(zhǔn)你調(diào)用的，如果你調(diào)用，我就“斷言”你調(diào)用錯(cuò)誤了。

關(guān)于異常處理的更詳細(xì)介紹，可以參考這篇文章：如何優(yōu)雅的設(shè)計(jì) Java 異常，應(yīng)該可以幫你更好的理解異常。

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/

bean 的驗(yàn)證

如果你認(rèn)為我上邊寫的那個(gè)添加用戶 API 寫的已經(jīng)非常完美了，那只能說明你還不是一個(gè)優(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ī)讉€(gè)通宵！

jsr 303 驗(yàn)證

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

再以上班的 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)化為一個(gè) api 異常（帶有錯(cuò)誤碼的異常）。

@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)證錯(cuò)誤異常
    }
}

BindingResult 是 Spring MVC 驗(yàn)證 DTO 后的一個(gè)結(jié)果集，可以參考 spring 官方文檔：

https://spring.io/

檢查參數(shù)后，可以拋出一個(gè)“帶驗(yàn)證碼的驗(yàn)證錯(cuò)誤異?！?。

擁抱 lombok

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

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

去掉 Setter 和 Getter

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

@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 的使用以及在使用時(shí)程序語義上的說明。

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

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

什么是鏈?zhǔn)斤L(fēng)格？我來舉個(gè)例子，看下面這個(gè) 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)用的時(shí)候，可以這樣使用：

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

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

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

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

List list = new ArrayList<>();

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

List list = Lists.newArrayList();

Lists 命名是一種約定（俗話說：約定優(yōu)于配置），它是指 Lists 是 List 這個(gè)類的一個(gè)工具類，那么使用 List 的工具類去產(chǎn)生 List，這樣的語義是不是要比直接 new 一個(gè)子類來的更直接一些呢，答案是肯定的。

再比如如果有一個(gè)工具類叫做 Maps，那你是否想到了創(chuàng)建 Map 的方法呢：

HashMap objectObjectHashMap = Maps.newHashMap();

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

再回過頭來看剛剛的 Student，很多時(shí)候，我們?nèi)?Student 這個(gè) bean 的時(shí)候，他會有一些必輸字段。

比如 Student 中的 name 字段，一般處理的方式是將 name 字段包裝成一個(gè)構(gòu)造方法，只有傳入 name 這樣的構(gòu)造方法，才能創(chuàng)建一個(gè) 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è)含參的構(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;
}