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

文章核心

其實舰攒，本不想把標題寫的那么恐怖抓歼，只是發(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è)務需要岩睁，以目前的知識儲備來講钞脂，都可以輕松應對，“沒有什么好學的”其實這句話沒有多大的問題捕儒，但是冰啃，如果你對編程還有一點點興趣邓夕，只是不知道如何努力或改進，希望本篇文章可以幫到你阎毅。如果你想進一步學習java歡迎來我的學習群（669823128）

技術(shù)點

本文不是一個吹噓的文章焚刚，不會講很多高深的架構(gòu)，相反扇调，會講解很多基礎(chǔ)的問題和寫法問題矿咕，如果讀者自認為基礎(chǔ)問題和寫法問題都是不是問題，那請忽略這篇文章狼钮，節(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是一個領(lǐng)域?qū)ο笤母覀冊僮鰝鹘y(tǒng)java軟件web開發(fā)中勺疼，這些domain都是貧血模型，是沒有行為的捏鱼，或是沒有足夠的領(lǐng)域模型的行為的恢口，所以，以這個理論來講穷躁，這些domain都應該是一個普通的entity對象，并非領(lǐng)域?qū)ο笠蚋荆哉埌寻臑?com.xxx.entity问潭。

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

DTO

數(shù)據(jù)傳輸我們應該使用DTO對象作為傳輸對象址芯，這是我們所約定的灾茁，因為很長時間我一直都在做移動端api設計的工作，有很多人告訴我谷炸，他們認為只有給手機端傳輸數(shù)據(jù)的時候(input or output)北专，這些對象成為DTO對象。請注意旬陡！這種理解是錯誤的拓颓，只要是用于網(wǎng)絡傳輸?shù)膶ο螅覀兌颊J為他們可以當做是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<S,T> {
    T convert(S s);
}

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

我們再來看接口實現(xiàn):
public class UserInputDTOConvert implements DTOConvert<userinputdto,user> {
@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 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中的轉(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<A, B> implements Function<A, B> {
    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<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;
         }
 }

看了這部分代碼以后球碉，你可能會問蜓斧，那逆向轉(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<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;
 }

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

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

看一下doBackward方法施禾，直接拋出了一個斷言異常帮碰，而不是業(yè)務異常，這段代碼告訴代碼的調(diào)用者拾积，這個方法不是準你調(diào)用的殉挽，如果你調(diào)用，我就”斷言”你調(diào)用錯誤了拓巧。

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 官方文檔

擁抱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<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("不支持逆向轉(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<String> list = new ArrayList<>();

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

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

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

HashMap<String, String> 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 <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上喜爷，“實現(xiàn)RestOperations所有的接口”,這個操作絕對不是一時半會可以寫完的，當時在重構(gòu)之前我?guī)缀鯇懥税雮€小時,如下:

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);
    }
    //其他實現(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點前進行下單忿危，那么發(fā)貨時間是明天达箍，如果今天下午3點后進行下單，那么發(fā)貨時間是后天铺厨，如果被確定的時間是周日缎玫，那么在此時間上再加1天為發(fā)貨時間。

思考與重構(gòu)

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

很多人可能看到這個需求咬摇，就動手開始寫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);
}
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é)果都當做一個變量嫂易，最終做一個三目運算符的方式進行返回兄朋，這樣的優(yōu)雅和可讀性顯而易見，當然這樣的代碼不是一蹴而就的怜械，我優(yōu)化了3遍產(chǎn)生的以上代碼颅和。讀者可根據(jù)自己的代碼和我寫的代碼進行對比。

提高方法

如果你做了3年+的程序員缕允，我相信像如上這樣的需求峡扩，你很輕松就能完成，但是如果你想做一個會寫java的程序員灼芭，就好好的思考和重構(gòu)代碼吧有额。
寫代碼就如同寫字一樣，同樣的字彼绷，大家都會寫巍佑，但是寫出來是否好看就不一定了。如果想把程序?qū)懞眉拿酰鸵粩嗟乃伎己椭貥?gòu)萤衰，敢于嘗試，敢于創(chuàng)新猜旬，不要因循守舊脆栋，一定要做一個優(yōu)秀的java程序員。
提高代碼水平最好的方法就是有條理的重構(gòu)洒擦！(注意：是有條理的重構(gòu))

設計模式

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

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

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

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

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

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

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

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

如果你想進一步學習java歡迎來我的學習群（669823128）

代碼設計

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

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

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

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

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

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

真不好意思尚困，我取了一個這么無聊的標題蠢箩。

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

“平時開發(fā)的時候贱鼻，做出的代碼總認為是正確的，而且寫法是完美的滋将×谛”，我相信這是大部分人的心聲耕渴，還回到剛剛的問題拘悦，如何在自己的世界中不斷提高呢？

答案就是:

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

你真的優(yōu)秀嗎橱脸？如果你每周都完成了學習源碼础米，回頭看自己代碼，然后勤于重構(gòu)添诉，我認為你就真的很優(yōu)秀了屁桑。

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

技能

UML

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

類圖
時序圖

clean code

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

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

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

linux 基礎(chǔ)命令

這點其實和會寫java沒有關(guān)系域携，但是linux很多時候確實承載運行java的容器，請學好linux的基礎(chǔ)命令鱼喉。

參考鳥哥的《Linux私房菜》

總結(jié)

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

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

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

如果你想進一步學習java歡迎來我的學習群（669823128）。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者

人面猴
序言：七十年代末灵巧，一起剝皮案震驚了整個濱河市搀矫，隨后出現(xiàn)的幾起案子，更是在濱河造成了極大的恐慌刻肄，老刑警劉巖瓤球，帶你破解...
沈念sama閱讀 206,839評論 6贊 482
死咒
序言：濱河連續(xù)發(fā)生了三起死亡事件，死亡現(xiàn)場離奇詭異敏弃，居然都是意外死亡卦羡，警方通過查閱死者的電腦和手機，發(fā)現(xiàn)死者居然都...
沈念sama閱讀 88,543評論 2贊 382
救了他兩次的神仙讓他今天三更去死
文/潘曉璐我一進店門麦到，熙熙樓的掌柜王于貴愁眉苦臉地迎上來绿饵，“玉大人，你說我怎么就攤上這事瓶颠∧馍蓿” “怎么了？”我有些...
開封第一講書人閱讀 153,116評論 0贊 344
道士緝兇錄：失蹤的賣姜人
文/不壞的土叔我叫張陵粹淋，是天一觀的道長吸祟。經(jīng)常有香客問我，道長桃移，這世上最難降的妖魔是什么屋匕？我笑而不...
開封第一講書人閱讀 55,371評論 1贊 279
?港島之戀（遺憾婚禮）
正文為了忘掉前任，我火速辦了婚禮借杰，結(jié)果婚禮上过吻，老公的妹妹穿的比我還像新娘。我一直安慰自己第步，他們只是感情好疮装，可當我...
茶點故事閱讀 64,384評論 5贊 374
惡毒庶女頂嫁案：這布局不是一般人想出來的
文/花漫我一把揭開白布。她就那樣靜靜地躺著粘都，像睡著了一般廓推。火紅的嫁衣襯著肌膚如雪。梳的紋絲不亂的頭發(fā)上翩隧，一...
開封第一講書人閱讀 49,111評論 1贊 285
城市分裂傳說
那天樊展，我揣著相機與錄音，去河邊找鬼堆生。笑死专缠，一個胖子當著我的面吹牛，可吹牛的內(nèi)容都是我干的淑仆。我是一名探鬼主播涝婉，決...
沈念sama閱讀 38,416評論 3贊 400
雙鴛鴦連環(huán)套：你想象不到人心有多黑
文/蒼蘭香墨我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼蔗怠！你這毒婦竟也來了墩弯？” 一聲冷哼從身側(cè)響起，我...
開封第一講書人閱讀 37,053評論 0贊 259
萬榮殺人案實錄
序言：老撾萬榮一對情侶失蹤寞射，失蹤者是張志新（化名）和其女友劉穎渔工，沒想到半個月后，有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體桥温，經(jīng)...
沈念sama閱讀 43,558評論 1贊 300
?護林員之死
正文獨居荒郊野嶺守林人離奇死亡引矩，尸身上長有42處帶血的膿包…… 初始之章·張勛以下內(nèi)容為張勛視角年9月15日...
茶點故事閱讀 36,007評論 2贊 325
?白月光啟示錄
正文我和宋清朗相戀三年，在試婚紗的時候發(fā)現(xiàn)自己被綠了侵浸。大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片旺韭。...
茶點故事閱讀 38,117評論 1贊 334
活死人
序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖掏觉，靈堂內(nèi)的尸體忽然破棺而出茂翔，到底是詐尸還是另有隱情，我是刑警寧澤履腋，帶...
沈念sama閱讀 33,756評論 4贊 324
?日本核電站爆炸內(nèi)幕
正文年R本政府宣布珊燎，位于F島的核電站，受9級特大地震影響遵湖，放射性物質(zhì)發(fā)生泄漏悔政。R本人自食惡果不足惜，卻給世界環(huán)境...
茶點故事閱讀 39,324評論 3贊 307
男人毒藥：我在死后第九天來索命
文/蒙蒙一延旧、第九天我趴在偏房一處隱蔽的房頂上張望谋国。院中可真熱鬧，春花似錦迁沫、人聲如沸芦瘾。這莊子的主人今日做“春日...
開封第一講書人閱讀 30,315評論 0贊 19
一樁弒父案，背后竟有這般陰謀
文/蒼蘭香墨我抬頭看了看天上的太陽近弟。三九已至缅糟，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間祷愉，已是汗流浹背窗宦。一陣腳步聲響...
開封第一講書人閱讀 31,539評論 1贊 262
情欲美人皮
我被黑心中介騙來泰國打工，沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留二鳄，地道東北人赴涵。一個月前我還...
沈念sama閱讀 45,578評論 2贊 355
代替公主和親
正文我出身青樓，卻偏偏與公主長得像订讼，于是被迫代替她去往敵國和親髓窜。傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當晚...
茶點故事閱讀 42,877評論 2贊 345