日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

導語

目前創(chuàng)新互聯(lián)公司已為上1000+的企業(yè)提供了網(wǎng)站建設、域名、網(wǎng)頁空間、網(wǎng)站托管、服務器租用、企業(yè)網(wǎng)站設計、竹山網(wǎng)站維護等服務，公司將堅持客戶導向、應用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

自2013年畢業(yè)后，今年已經(jīng)是我工作的第4個年頭了，總在做java相關(guān)的工作，終于有時間坐下來，寫一篇關(guān)于java寫法的一篇文章，來探討一下如果你真的是一個java程序員，那你真的會寫java嗎?

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

文章核心

其實，本不想把標題寫的那么恐怖，只是發(fā)現(xiàn)很多人干了幾年java以后，都自認為是一個不錯的java程序員了，可以拿著上萬的工資都處宣揚自己了，寫這篇文章的目的并不是嘲諷和我一樣做java的同行們，只是希望讀者看到此騙文章后，可以和我一樣，心平氣和的爭取做一個優(yōu)秀的程序員。

講述方向

由于一直從事移動互聯(lián)網(wǎng)相關(guān)工作，java開發(fā)中經(jīng)常和移動端打交道或者做一些后端的工作，所以本篇文章更可能涉及和移動端的交互或者與后端的交互方式，筆者希望以自身的一些學習經(jīng)驗或者開發(fā)經(jīng)驗，可以帶動認真閱讀本篇文章的讀者們，讓大家對java有一個更好的態(tài)度去學習它，它不只是一個賺錢的工具而已。

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

技術(shù)點

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

開發(fā)工具

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

更換IDE

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

別告訴我快捷鍵不好用

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

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

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

bean

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

domain包名

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

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

DTO

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

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

DTO轉(zhuǎn)化

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

場景

比如添加會員操作，由于用于演示，我只考慮用戶的一些簡單數(shù)據(jù)，當后臺管理員點擊添加用戶時，只需要傳過來用戶的姓名和年齡就可以了，后端接受到數(shù)據(jù)后，將添加創(chuàng)建時間和更新時間和默認密碼三個字段，然后保存數(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個字段，我們要如何做呢? 一個一個進行set數(shù)據(jù)嗎?當然，如果你這么做了，肯定不會有什么問題，但是，這肯定不是一個最優(yōu)的做法。

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

 
 
 

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

  
  
  
    return userService.addUser(user);
  
  
  
}
 
 
 

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

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

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

 
 
 

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

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

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

抽象接口定義

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

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

看一下抽象后的接口:

 
 
 

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

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

我們再來看接口實現(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程序員，我相信你應該和我一樣，已經(jīng)數(shù)次重復review過自己的代碼很多次了。

我們再看這個保存用戶的例子，你將發(fā)現(xiàn)，api中返回值是有些問題的，問題就在于不應該直接返回User實體，因為如果這樣的話，就暴露了太多實體相關(guān)的信息，這樣的返回值是不安全的，所以我們更應該返回一個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)，那我們應該考慮一下，是否可以將這個類和DTO進行聚合呢，看一下我的聚合結(jié)果:

 
 
 

  
  
  
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)化的行為，我相信這樣的操作可以讓代碼的可讀性變得更強，并且是符合語義的。

再查工具類

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

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

我仔細閱讀了一下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)化會有什么用呢?其實我們有很多小的業(yè)務需求中，入?yún)⒑统鰠⑹且粯拥模敲次覀冏兛梢暂p松的進行轉(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;
  
  
  
 }
 
 
 

當然，上述只是表明了轉(zhuǎn)化方向的正向或逆向，很多業(yè)務需求的出參和入?yún)⒌腄TO對象是不同的，那么你需要更明顯的告訴程序：逆向是無法調(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è)務異常，這段代碼告訴代碼的調(diào)用者，這個方法不是準你調(diào)用的，如果你調(diào)用，我就”斷言”你調(diào)用錯誤了。

關(guān)于異常處理的更詳細介紹，可以參考我之前的文章:如何優(yōu)雅的設計java異常 ，應該可以幫你更好的理解異常。

bean的驗證

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

為什么要驗證

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

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

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

jsr 303驗證

hibernate提供的jsr 303實現(xiàn)，我覺得目前仍然是很優(yōu)秀的，具體如何使用，我不想講，因為谷歌上你可以搜索出很多答案!

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

 
 
 

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

我們需要將驗證結(jié)果傳給前端，這種異常應該轉(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 帶驗證碼的驗證錯誤異常
  
  
  
     }
  
  
  
}
 
 
 

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

檢查參數(shù)后，可以拋出一個“帶驗證碼的驗證錯誤異?！保唧w異常設計可以參考如何優(yōu)雅的設計java異常

擁抱lombok

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

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

去掉Setter和Getter

其實這個標題，我不太想說，因為網(wǎng)上太多，但是因為很多人告訴我，他們根本就不知道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 {
  
  
  
        @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的強大。我希望寫一些網(wǎng)上很難查到，或者很少人進行說明的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，調(diào)用的時候，可以這樣使用:

 
 
 

  
  
  
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來講很友好的鏈式操作。

靜態(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)慡tudent這個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)造方法)要好很多。

當然，看過很多源碼以后，我想相信將靜態(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");
 
 
 

當然他仍然是支持鏈式調(diào)用的:

 
 
 

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

這樣來寫代碼，真的很簡潔，并且可讀性很強。

使用builder

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

今天其實要說的是一種變種的builder模式，那就是構(gòu)建bean的builder模式，其實主要的思想是帶著大家一起看一下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最為底層包裝器進行包裝器模式的設計:

 
 
 

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

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

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

然后再由擴展類對FilterRestTemplate進行包裝擴展:

 
 
 

  
  
  
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 {
  
  
  
                                                 

                                                名稱欄目：細思極恐-你真的會寫Java嗎?                                                

                                                鏈接分享：http://m.5511xx.com/article/dhpccss.html