你真的會寫java嗎？希望你看完后也能成為合格的Java工程師

技術點

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

講述方向

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

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

開發工具

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

更換IDE

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

別告訴我快捷鍵不好用

更換IDE不在我本文的重點內容中，所以不下想用太多的篇幅去寫為什么更換IDE，請谷歌。在這里，我只能告訴你，更換IDE只為了更好、更快的寫好java代碼。原因略。別告訴我快捷鍵不好用，請嘗試新事物。

bean

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

domain包名

根據很多java程序員的”經驗”來看，一個數據庫表則對應著一個domain對象，所以很多程序員在寫代碼時，包名則使用：com.xxx.domain ，這樣寫好像已經成為了行業的一種約束，數據庫映射對象就應該是domain。但是你錯了，domain 是一個領域對象，往往我們再做傳統java軟件web開發中，這些domain都是貧血模型，是沒有行為的，或是沒有足夠的領域模型的行為的，所以，以這個理論來講，這些domain都應該是一個普通的entity對象，并非領域對象，所以請把包名改為:com.xxx.entity。

DTO

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

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

DTO轉化

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

場景

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

@RequestMapping(
"/v1/api/user")


@RestController


publicclass 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數據嗎？當然，如果你這么做了，肯定不會有什么問題，但是，這肯定不是一個最優的做法。

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

@PostMapping


public 
User 
addUser
(UserInputDTO userInputDTO){

    User user = 
new User();

    BeanUtils.copyProperties(userInputDTO,user);



    
return userService.addUser(user);

}

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

轉化的語義

上邊的轉化過程，讀者看后肯定覺得優雅很多，但是我們再寫java代碼時，更多的需要考慮語義的操作，再看上邊的代碼:

User user = 
new User();

BeanUtils.copyProperties(userInputDTO,user);

雖然這段代碼很好的簡化和優化了代碼，但是他的語義是有問題的，我們需要提現一個轉化過程才好,所以代碼改成如下:

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

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

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

抽象接口定義

當實際工作中，完成了幾個api的DTO轉化時，我們會發現，這樣的操作有很多很多，那么應該定義好一個接口，讓所有這樣的操作都有規則的進行。如果接口被定義以后，那么convertFor這個方法的語義將產生變化，他將是一個實現類。

看一下抽象后的接口:

public 

interface 
DTOConvert<
S,
T> {

    
T 
convert
(S s);

}

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

我們再來看接口實現:

publicclass UserInputDTOConvert implements DTOConvert {


@Override


public 
User 
convert
(UserInputDTO userInputDTO) {

User user = 
new User();

BeanUtils.copyProperties(userInputDTO,user);


return user;

}

}

我們這樣重構后，我們發現現在的代碼是如此的簡潔，并且那么的規范:

@RequestMapping(
"/v1/api/user")


@RestController


publicclass UserApi {



    
@Autowired

    
private UserService userService;



    
@PostMapping

    

public User 
addUser
(UserInputDTO userInputDTO){

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



        
return userService.addUser(user);

    }

}

review code

如果你是一個優秀的java程序員，我相信你應該和我一樣，已經數次重復review過自己的代碼很多次了。我們再看這個保存用戶的例子，你將發現，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才更健全。

不知道在看完這段代碼之后，讀者有是否發現還有其他問題的存在，作為一個優秀的java程序員，請看一下這段我們剛剛抽象完的代碼:User user = new UserInputDTOConvert().convert(userInputDTO);

你會發現，new這樣一個DTO轉化對象是沒有必要的，而且每一個轉化對象都是由在遇到DTO轉化的時候才會出現，那我們應該考慮一下，是否可以將這個類和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內部轉化的代碼，它實現了我們自己定義的DTOConvert接口，但是這樣真的就沒有問題，不需要再思考了嗎？我覺得并不是，對于Convert這種轉化語義來講，很多工具類中都有這樣的定義，這中Convert并不是業務級別上的接口定義，它只是用于普通bean之間轉化屬性值的普通意義上的接口定義，所以我們應該更多的去讀其他含有Convert轉化語義的代碼。我仔細閱讀了一下GUAVA的源碼，發現了
com.google.common.base.Convert這樣的定義:

publicabstractclass Converter<A, B> implements Function<A, B> {

    

protected 
abstract B 
doForward(
A a);

    

protected 
abstract A 
doBackward(
B b);

    
//其他略


}

從源碼可以了解到，GUAVA中的Convert可以完成正向轉化和逆向轉化，繼續修改我們DTO中轉化的這段代碼:

privatestaticclass UserInputDTOConvert implements DTOConvert<UserInputDTO,User> {

        
@Override

        

public User 
convert
(UserInputDTO userInputDTO) {

                User user = 
new User();

                BeanUtils.copyProperties(userInputDTO,user);

                
return user;

        }

}

修改后:

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

         }

 }

看了這部分代碼以后，你可能會問，那逆向轉化會有什么用呢？其實我們有很多小的業務需求中，入參和出參是一樣的，那么我們變可以輕松的進行轉化，我將上邊所提到的UserInputDTO和UserOutputDTO都轉成UserDTO展示給大家:

DTO：

publicclass UserDTO {

    
private String username;

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

    }



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

 }

當然，上述只是表明了轉化方向的正向或逆向，很多業務需求的出參和入參的DTO對象是不同的，那么你需要更明顯的告訴程序：逆向是無法調用的:

privatestaticclass 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) {

                 
thrownew 
AssertionError
(
"不支持逆向轉化方法!");

         }

 }

看一下doBackward方法，直接拋出了一個斷言異常，而不是業務異常，這段代碼告訴代碼的調用者，這個方法不是準你調用的，如果你調用，我就”斷言”你調用錯誤了。

bean的驗證

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

為什么要驗證很多人會告訴我，如果這些api是提供給前端進行調用的，前端都會進行驗證啊，你為什還要驗證？其實答案是這樣的，我從不相信任何調用我api或者方法的人，比如前端驗證失敗了，或者某些人通過一些特殊的渠道(比如Charles進行抓包),直接將數據傳入到我的api，那我仍然進行正常的業務邏輯處理，那么就有可能產生臟數據！“對于臟數據的產生一定是致命”，這句話希望大家牢記在心，再小的臟數據也有可能讓你找幾個通宵！

jsr 303驗證

hibernate提供的jsr 303實現，我覺得目前仍然是很優秀的，具體如何使用，我不想講，因為谷歌上你可以搜索出很多答案! 再以上班的api實例進行說明，我們現在對DTO數據進行檢查:

publicclass UserDTO {

    @NotNull

    private String username;

    @NotNull

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

擁抱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方法已經去掉了。但是上邊的例子根本不足以體現lombok的強大。我希望寫一些網上很難查到，或者很少人進行說明的lombok的使用以及在使用時程序語義上的說明。比如:@Data,@AllArgsConstructor,@NoArgsConstructor…這些我就不進行一一說明了，請大家自行查詢資料.

bean中的鏈式風格

什么是鏈式風格？我來舉個例子，看下面這個Student的bean:

publicclass Student {

    
private String name;

    privateint age;



    

public String 
getName
() {

        
return name;

    }



    

public Student 
setName
(String name) {

        
this.name = name;

        returnthis;

    }



    

public 
int 
getAge
() {

        
return age;

    }



    

public Student 
setAge
(
int age) {

        returnthis;

    }

}

仔細看一下set方法，這樣的設置便是chain的style，調用的時候，可以這樣使用:

Student student = 
new Student()

        .setAge(
24)

        .setName(
"zs");

相信合理使用這樣的鏈式代碼，會更多的程序帶來很好的可讀性，那看一下如果使用lombok進行改善呢，請使用 @Accessors(chain = true),看如下代碼:

@Accessors(chain = true)


@Setter


@Getter


publicclass Student {

    
private 
String 
name;

    
privateint 
age;

}

這樣就完成了一個對于bean來講很友好的鏈式操作。

靜態構造方法

靜態構造方法的語義和簡化程度真的高于直接去new一個對象。比如new一個List對象，過去的使用是這樣的:List list = new ArrayList<>();

看一下guava中的創建方式:List list = Lists.newArrayList();

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

HashMap<String, String> objectObjectHashMap = Maps.newHashMap();好了，如果你理解了我說的語義，那么，你已經向成為java程序員更近了一步了。

再回過頭來看剛剛的Student，很多時候，我們去寫Student這個bean的時候，他會有一些必輸字段，比如Student中的name字段，一般處理的方式是將name字段包裝成一個構造方法，只有傳入name這樣的構造方法，才能創建一個Student對象。

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

當然，看過很多源碼以后，我想相信將靜態構造方法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狀態:

publicclass Student {

    
private String name;

    privateint 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
(){

            
returnnew 
Builder
();

    }

    publicstaticclass Builder{

            
private String name;

            privateint age;

            

public Builder 
name
(String name){

                    
this.name = name;

                    returnthis;

            }



            

public Builder 
age
(
int age){

                    
this.age = age;

                    returnthis;

            }



            

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


publicclass Student {

    
private 
String name;

    privateint age;

}

調用方式:Student student = Student.builder().name(“zs”).age(24).build();

代理模式

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

所以我們考慮將RestTemplate最為底層包裝器進行包裝器模式的設計:

publicabstractclass FilterRestTemplate implements RestOperations {

        protectedvolatile RestTemplate restTemplate;



        

protected 
FilterRestTemplate
(RestTemplate restTemplate){

                
this.restTemplate = restTemplate;

        }



        
//實現RestOperations所有的接口


}

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

publicclass 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上，“實現RestOperations所有的接口”,這個操作絕對不是一時半會可以寫完的，當時在重構之前我幾乎寫了半個小時,如下:

publicabstractclass FilterRestTemplate implements RestOperations {



    protectedvolatile 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);

    }

    
//其他實現代碼略。。。


}

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

@AllArgsConstructor


public 
abstract 

class 
FilterRestTemplate 
implements 
RestOperations {

    
@Delegate

    
protected 
volatile RestTemplate restTemplate;

}

這幾行代碼完全替代上述那些冗長的代碼。是不是很簡潔，做一個擁抱lombok的程序員吧。

重構需求案例項目需求

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

思考與重構

我相信這個需求看似很簡單，無論怎么寫都可以完成。很多人可能看到這個需求，就動手開始寫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() ;

}

讀這段代碼的時候，你會發現，我將判斷和有可能出現的不同結果都當做一個變量，最終做一個三目運算符的方式進行返回，這樣的優雅和可讀性顯而易見，當然這樣的代碼不是一蹴而就的，我優化了3遍產生的以上代碼。讀者可根據自己的代碼和我寫的代碼進行對比。

提高方法

如果你做了3年+的程序員，我相信像如上這樣的需求，你很輕松就能完成，但是如果你想做一個會寫java的程序員，就好好的思考和重構代碼吧。寫代碼就如同寫字一樣，同樣的字，大家都會寫，但是寫出來是否好看就不一定了。如果想把程序寫好，就要不斷的思考和重構，敢于嘗試，敢于創新，不要因循守舊，一定要做一個優秀的java程序員。提高代碼水平最好的方法就是有條理的重構！(注意：是有條理的重構)

設計模式

設計模式就是工具，而不是提現你是否是高水平程序員的一個指標。我經常會看到某一個程序員興奮的大喊，哪個程序哪個點我用到了設計模式，寫的多么多么優秀，多么多么好。我仔細去翻閱的時候，卻發現有很多是過度設計的。

業務驅動技術 or 技術驅動業務

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

業務驅動技術：如果你所在的項目是一個收益很小或者甚至沒有收益的項目，請不要搞其他創新的東西，不要驅動業務要如何如何做，而是要熟知業務現在的痛點是什么？如何才能幫助業務盈利或者讓項目更好，更順利的進行。

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

我相信大部分人還都處于業務驅動技術的方向吧。所以你既然不能驅動業務，那就請擁抱業務變化吧。

代碼設計

一直在做java后端的項目，經常會有一些變動，我相信大家也都遇到過。比如當我們寫一段代碼的時候，我們考慮將需求映射成代碼的狀態模式，突然有一天，狀態模式里邊又添加了很多行為變化的東西，這時候你就撓頭了，你硬生生的將狀態模式中添加過多行為和變化。

慢慢的你會發現這些狀態模式，其實更像是一簇算法，應該使用策略模式，這時你應該已經暈頭轉向了。

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

java編程中沒有銀彈，請擁抱業務變化，一直思考重構，你就有一個更好的代碼設計!

你真的優秀嗎？

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

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

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

答案就是:

多看成熟框架的源碼多回頭看自己的代碼勤于重構你真的優秀嗎？如果你每周都完成了學習源碼，回頭看自己代碼，然后勤于重構，我認為你就真的很優秀了。即使也許你只是剛剛入門，但是一直堅持，你就是一個真的會寫java代碼的程序員了。

技能

UML不想多討論UML相關的知識，但是我覺得你如果真的會寫java，請先學會表達自己，UML就是你說話的語言，做一名優秀的java程序員，請至少學會這兩種UML圖：類圖時序圖clean code

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

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

linux 基礎命令這點其實和會寫java沒有關系，但是linux很多時候確實承載運行java的容器，請學好linux的基礎命令。

總結

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

本文從寫java程序的小方面一直寫到大方面，來闡述了如何才能寫好java程序，并告訴大家如何才能提高自身的編碼水平。

我希望看到這篇文章的各位都能做一個優秀的java程序員。

原文地址：http://lrwinx.github.io

上篇文章中，不少伙伴留言我說希望出些視頻教程，也還有些伙伴是剛入門Java不久的，花時間整理了一些視頻教程，你們要學的伙伴，回復：Java教程，即可領取！

Java 900集全套視頻教程（全家桶）
https://pan.baidu.com/s/1M6jerq2F3JSd9PDeLbqBtA 提取碼: vp

進階的實戰案例目前也還在整理中。伙伴們可以期待一下！