技術點

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

開發(fā)工具

不知道有多少”老”程序員還在使用 Eclipse牵署，這些程序員們要不就是因循守舊，要不就是根本就不知道其他好的開發(fā)工具的存在喧半，Eclipse 吃內存卡頓的現(xiàn)象以及各種偶然莫名異常的出現(xiàn)奴迅，都告知我們是時候尋找新的開發(fā)工具了。

更換 IDE

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

別告訴我快捷鍵不好用

更換 IDE 不在我本文的重點內容中，所以不想用太多的篇幅去寫為什么更換IDE做葵。在這里占哟，我只能告訴你，更換 IDE 只為了更好酿矢、更快的寫好 Java 代碼榨乎。原因略。

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

Bean

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

domain 包名

根據很多 Java 程序員的”經驗”來看隐绵，一個數據庫表則對應著一個 domain 對象，所以很多程序員在寫代碼時拙毫，包名則使用：com.xxx.domain 依许，這樣寫好像已經成為了行業(yè)的一種約束，數據庫映射對象就應該是 domain缀蹄。但是你錯了峭跳，domain 是一個領域對象，往往我們再做傳統(tǒng) Java 軟件 Web 開發(fā)中缺前，這些 domain 都是貧血模型蛀醉，是沒有行為的，或是沒有足夠的領域模型的行為的衅码，所以拯刁，以這個理論來講，這些 domain 都應該是一個普通的 entity 對象逝段，并非領域對象垛玻，所以請把包名改為:com.xxx.entity。

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

DTO

數據傳輸我們應該使用 DTO 對象作為傳輸對象，這是我們所約定的颊乘，因為很長時間我一直都在做移動端 API 設計的工作参淹，有很多人告訴我，他們認為只有給手機端傳輸數據的時候(input or output)乏悄，這些對象成為 DTO 對象浙值。請注意！這種理解是錯誤的檩小，只要是用于網絡傳輸的對象开呐，我們都認為他們可以當做是 DTO 對象，比如電商平臺中规求，用戶進行下單筐付，下單后的數據，訂單會發(fā)到 OMS 或者 ERP 系統(tǒng)阻肿，這些對接的返回值以及入參也叫 DTO 對象瓦戚。

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

DTO 轉化

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

場景

比如添加會員操作，由于用于演示奸焙，我只考慮用戶的一些簡單數據瞎暑，當后臺管理員點擊添加用戶時，只需要傳過來用戶的姓名和年齡就可以了忿偷，后端接受到數據后金顿，將添加創(chuàng)建時間和更新時間和默認密碼三個字段，然后保存數據庫鲤桥。

@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 數據嗎箱沦？當然辩恼，如果你這么做了，肯定不會有什么問題谓形，但是灶伊，這肯定不是一個最優(yōu)的做法。

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

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

    return userService.addUser(user);
}

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

轉化的語義

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

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

雖然這段代碼很好的簡化和優(yōu)化了代碼肴捉，但是他的語義是有問題的腹侣，我們需要提現(xià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)。

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

抽象接口定義

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

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

看一下抽象后的接口：

public interface DTOConvert<S,T> {
    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;
}
}

我們這樣重構后，我們發(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 程序員夕玩，我相信你應該和我一樣泪幌，已經數次重復 review 過自己的代碼很多次了。

我們再看這個保存用戶的例子馒过，你將發(fā)現(xiàn)臭脓，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 才更健全葫录。

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

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

你會發(fā)現(xiàn)，new 這樣一個 DTO 轉化對象是沒有必要的摔竿，而且每一個轉化對象都是由在遇到 DTO 轉化的時候才會出現(xiàn)面粮，那我們應該考慮一下，是否可以將這個類和 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 內部轉化的代碼冷溃，它實現(xiàn)了我們自己定義的 DTOConvert 接口，但是這樣真的就沒有問題梦裂，不需要再思考了嗎似枕？

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

我仔細閱讀了一下 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 可以完成正向轉化和逆向轉化虐拓，繼續(xù)修改我們 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;
         }
 }

看了這部分代碼以后，你可能會問傲武，那逆向轉化會有什么用呢蓉驹？其實我們有很多小的業(yè)務需求中，入參和出參是一樣的揪利，那么我們變可以輕松的進行轉化态兴，我將上邊所提到的 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;
    }

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

當然疟位，上述只是表明了轉化方向的正向或逆向瞻润，很多業(yè)務需求的出參和入參的 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 方法，直接拋出了一個斷言異常绍撞，而不是業(yè)務異常正勒，這段代碼告訴代碼的調用者，這個方法不是準你調用的楚午，如果你調用昭齐，我就”斷言”你調用錯誤了。

Bean 的驗證

如果你認為我上邊寫的那個添加用戶 API 寫的已經非常完美了矾柜，那只能說明你還不是一個優(yōu)秀的程序員阱驾。我們應該保證任何數據的入參到方法體內都是合法的。

為什么要驗證

很多人會告訴我怪蔑，如果這些 API 是提供給前端進行調用的里覆，前端都會進行驗證啊，你為什還要驗證缆瓣？

其實答案是這樣的喧枷，我從不相信任何調用我 API 或者方法的人，比如前端驗證失敗了弓坞，或者某些人通過一些特殊的渠道(比如 Charles 進行抓包)隧甚，直接將數據傳入到我的 API，那我仍然進行正常的業(yè)務邏輯處理渡冻，那么就有可能產生臟數據戚扳！

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

jsr 303驗證

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

再以上班的 API 實例進行說明巍举，我們現(xiàn)在對 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 官方文檔（http://spring.io/）简烘。

擁抱 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 方法已經去掉了福扬。

但是上邊的例子根本不足以體現(xiàn) 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 來講很友好的鏈式操作颂砸。

靜態(tài)構造方法

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

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

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

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

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

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

好了戳护，如果你理解了我說的語義金抡，那么，你已經向成為 Java 程序員更近了一步了腌且。

再回過頭來看剛剛的 Student梗肝，很多時候，我們去寫 Student 這個 bean 的時候铺董，他會有一些必輸字段巫击，比如 Student 中的 name 字段，一般處理的方式是將 name 字段包裝成一個構造方法，只有傳入 name 這樣的構造方法坝锰，才能創(chuàng)建一個 Student 對象粹懒。

接上上邊的靜態(tài)構造方法和必傳參數的構造方法，使用 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 的構造方法)要好很多顷级。

當然凫乖，看過很多源碼以后，我想相信將靜態(tài)構造方法 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 狀態(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;
            }
    }

}

調用方式：

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 狀態(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 所有的接口”,這個操作絕對不是一時半會可以寫完的钙姊，當時在重構之前我?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 的程序員吧基跑。

重構

需求案例

項目需求

項目開發(fā)階段婚温，有一個關于下單發(fā)貨的需求：如果今天下午 3 點前進行下單，那么發(fā)貨時間是明天媳否，如果今天下午 3 點后進行下單缭召，那么發(fā)貨時間是后天栈顷，如果被確定的時間是周日，那么在此時間上再加 1 天為發(fā)貨時間嵌巷。

思考與重構

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

很多人可能看到這個需求搪哪，就動手開始寫 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)的不同結果都當做一個變量，最終做一個三目運算符的方式進行返回隧期，這樣的優(yōu)雅和可讀性顯而易見飒责，當然這樣的代碼不是一蹴而就的，我優(yōu)化了 3 遍產生的以上代碼仆潮。讀者可根據自己的代碼和我寫的代碼進行對比宏蛉。

提高方法

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

寫代碼就如同寫字一樣辟灰，同樣的字，大家都會寫篡石，但是寫出來是否好看就不一定了芥喇。如果想把程序寫好，就要不斷的思考和重構凰萨，敢于嘗試继控，敢于創(chuàng)新械馆，不要因循守舊，一定要做一個優(yōu)秀的 Java 程序員武通。

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

設計模式

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

我經常會看到某一個程序員興奮的大喊尾菇，哪個程序哪個點我用到了設計模式，寫的多么多么優(yōu)秀囚枪，多么多么好派诬。我仔細去翻閱的時候，卻發(fā)現(xiàn)有很多是過度設計的链沼。

業(yè)務驅動技術 or 技術驅動業(yè)務

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

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

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

我相信大部分人還都處于業(yè)務驅動技術的方向吧粥诫。

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

代碼設計

一直在做 Java 后端的項目怀浆，經常會有一些變動谊囚，我相信大家也都遇到過怕享。

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

慢慢的你會發(fā)現(xiàn)這些狀態(tài)模式，其實更像是一簇算法芳来，應該使用策略模式，這時你應該已經暈頭轉向了猜拾。

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

Java 編程中沒有銀彈紊搪，請擁抱業(yè)務變化，一直思考重構全景，你就有一個更好的代碼設計!

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

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

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

“平時開發(fā)的時候鳖轰，做出的代碼總認為是正確的清酥，而且寫法是完美的〈圉”总处，我相信這是大部分人的心聲，還回到剛剛的問題睛蛛，如何在自己的世界中不斷提高呢鹦马？

答案就是:

• 多看成熟框架的源碼
• 多回頭看自己的代碼
• 勤于重構
  你真的優(yōu)秀嗎胧谈？ 如果你每周都完成了學習源碼，回頭看自己代碼荸频，然后勤于重構菱肖，我認為你就真的很優(yōu)秀了。

即使也許你只是剛剛入門旭从，但是一直堅持稳强，你就是一個真的會寫java代碼的程序員了。