建站
咨詢
售后
建站咨詢
新聞中心
文章存在大量代碼段，本來為了良好的視覺效果，打算用圖片來代替。但是考慮到無法復(fù)制，所以還是用文字了。各位看官見諒。
創(chuàng)新互聯(lián)建站長期為成百上千客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為陽泉企業(yè)提供專業(yè)的成都網(wǎng)站制作、網(wǎng)站設(shè)計、外貿(mào)網(wǎng)站建設(shè)，陽泉網(wǎng)站改版等技術(shù)服務(wù)。擁有10多年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。
-正文-
文章核心
其實，本不想把標(biāo)題寫的那么恐怖，只是發(fā)現(xiàn)很多人干了幾年java以后，都自認(rèn)為是一個不錯的java程序員了，可以拿著上萬的工資都處宣揚(yáng)自己了，寫這篇文章的目的并不是嘲諷和我一樣做java的同行們，只是希望讀者看到此騙文章后，可以和我一樣，心平氣和的爭取做一個優(yōu)秀的程序員。
講述方向
由于一直從事移動互聯(lián)網(wǎng)相關(guān)工作，java開發(fā)中經(jīng)常和移動端打交道或者做一些后端的工作，所以本篇文章更可能涉及和移動端的交互或者與后端的交互方式，筆者希望以自身的一些學(xué)習(xí)經(jīng)驗或者開發(fā)經(jīng)驗，可以帶動認(rèn)真閱讀本篇文章的讀者們，讓大家對java有一個更好的態(tài)度去學(xué)習(xí)它，它不只是一個賺錢的工具而已。
筆者身邊有很多與筆者年齡相仿或年齡更大的朋友或同事，經(jīng)常有人問我：“你現(xiàn)在還在學(xué)習(xí)嗎?我覺得沒什么好學(xué)的，這些東西都差不多”，我總是回答只要有時間，我就要看一會書，這個時候，大家都會露出一副不屑的眼神或笑容。
其實，非常能理解身邊朋友或同事的看法，以目前狀態(tài)來講，大多都是工作至少5年的程序員了，對于公司大大小小的業(yè)務(wù)需要，以目前的知識儲備來講，都可以輕松應(yīng)對，“沒有什么好學(xué)的”其實這句話沒有多大的問題，但是，如果你對編程還有一點點興趣，只是不知道如何努力或改進(jìn)，希望本篇文章可以幫到你。
技術(shù)點
本文不是一個吹噓的文章，不會講很多高深的架構(gòu)，相反，會講解很多基礎(chǔ)的問題和寫法問題，如果讀者自認(rèn)為基礎(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ù)庫表則對應(yīng)著一個domain對象，所以很多程序員在寫代碼時，包名則使用：com.xxx.domain ，這樣寫好像已經(jīng)成為了行業(yè)的一種約束，數(shù)據(jù)庫映射對象就應(yīng)該是domain。
但是你錯了，domain是一個領(lǐng)域?qū)ο?，往往我們再做傳統(tǒng)java軟件web開發(fā)中，這些domain都是貧血模型，是沒有行為的，或是沒有足夠的領(lǐng)域模型的行為的，所以，以這個理論來講，這些domain都應(yīng)該是一個普通的entity對象，并非領(lǐng)域?qū)ο?，所以請把包名改?com.xxx.entity。
如果你還不理解我說的話，請看一下Vaughn Vernon出的一本叫做《IMPLEMENTING DOMAIN-DRIVEN DESIGN》(實現(xiàn)領(lǐng)域驅(qū)動設(shè)計)這本書，書中講解了貧血模型與領(lǐng)域模型的區(qū)別，相信你會受益匪淺。
DTO
數(shù)據(jù)傳輸我們應(yīng)該使用DTO對象作為傳輸對象，這是我們所約定的，因為很長時間我一直都在做移動端api設(shè)計的工作，有很多人告訴我，他們認(rèn)為只有給手機(jī)端傳輸數(shù)據(jù)的時候(input or output)，這些對象成為DTO對象。
請注意!這種理解是錯誤的，只要是用于網(wǎng)絡(luò)傳輸?shù)膶ο?，我們都認(rèn)為他們可以當(dāng)做是DTO對象，比如電商平臺中，用戶進(jìn)行下單，下單后的數(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ù)，當(dāng)后臺管理員點擊添加用戶時，只需要傳過來用戶的姓名和年齡就可以了，后端接受到數(shù)據(jù)后，將添加創(chuàng)建時間和更新時間和默認(rèn)密碼三個字段，然后保存數(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個字段，我們要如何做呢? 一個一個進(jìn)行set數(shù)據(jù)嗎?當(dāng)然，如果你這么做了，肯定不會有什么問題，但是，這肯定不是一個最優(yōu)的做法。
網(wǎng)上有很多工具，支持淺拷貝或深拷貝的Utils. 舉個例子，我們可以使用org.springframework.beans.BeanUtils#copyProperties對代碼進(jìn)行重構(gòu)和優(yōu)化:
@PostMapping public User addUser(UserInputDTO userInputDTO){ User user = new User(); BeanUtils.copyProperties(userInputDTO,user); return userService.addUser(user); }
BeanUtils.copyProperties是一個淺拷貝方法，復(fù)制屬性時，我們只需要把DTO對象和要轉(zhuǎn)化的對象兩個的屬性值設(shè)置為一樣的名稱，并且保證一樣的類型就可以了。如果你在做DTO轉(zhuǎn)化的時候一直使用set進(jìn)行屬性賦值，那么請嘗試這種方式簡化代碼，讓代碼更加清晰!
轉(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; }
這是一個更好的語義寫法，雖然他麻煩了些，但是可讀性大大增加了，在寫代碼時，我們應(yīng)該盡量把語義層次差不多的放到一個方法中，比如:
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) 改善既有代碼的設(shè)計) 這本書中的Extract Method重構(gòu)方式。
抽象接口定義
當(dāng)實際工作中，完成了幾個api的DTO轉(zhuǎn)化時，我們會發(fā)現(xiàn)，這樣的操作有很多很多，那么應(yīng)該定義好一個接口，讓所有這樣的操作都有規(guī)則的進(jìn)行。
如果接口被定義以后，那么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程序員，我相信你應(yīng)該和我一樣，已經(jīng)數(shù)次重復(fù)review過自己的代碼很多次了.
我們再看這個保存用戶的例子，你將發(fā)現(xiàn)，api中返回值是有些問題的，問題就在于不應(yīng)該直接返回User實體，因為如果這樣的話，就暴露了太多實體相關(guān)的信息，這樣的返回值是不安全的，所以我們更應(yīng)該返回一個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)，那我們應(yīng)該考慮一下，是否可以將這個類和DTO進(jìn)行聚合呢，看一下我的聚合結(jié)果:
public class UserInputDTO { private String username; private int age; public String getUsername() { return username; } public void setUsername(String username) { this.username = username; } public int getAge() { return age; } public void setAge(int age) { this.age = age; } public User convertToUser(){ UserInputDTOConvert userInputDTOConvert = new UserInputDTOConvert(); User convert = userInputDTOConvert.convert(this); return convert; } private static class UserInputDTOConvert implements DTOConvert { @Override public User convert(UserInputDTO userInputDTO) { User user = new User(); BeanUtils.copyProperties(userInputDTO,user); return user; } } }
然后api中的轉(zhuǎn)化則由:
User user = new UserInputDTOConvert().convert(userInputDTO); User saveUserResult = userService.addUser(user);
變成了:
User user = userInputDTO.convertToUser(); User saveUserResult = userService.addUser(user);
我們再DTO對象中添加了轉(zhuǎn)化的行為，我相信這樣的操作可以讓代碼的可讀性變得更強(qiáng)，并且是符合語義的。
再查工具類
再來看DTO內(nèi)部轉(zhuǎn)化的代碼，它實現(xiàn)了我們自己定義的DTOConvert接口，但是這樣真的就沒有問題，不需要再思考了嗎?
我覺得并不是，對于Convert這種轉(zhuǎn)化語義來講，很多工具類中都有這樣的定義，這中Convert并不是業(yè)務(wù)級別上的接口定義，它只是用于普通bean之間轉(zhuǎn)化屬性值的普通意義上的接口定義，所以我們應(yīng)該更多的去讀其他含有Convert轉(zhuǎn)化語義的代碼。
我仔細(xì)閱讀了一下GUAVA的源碼，發(fā)現(xiàn)了com.google.common.base.Convert這樣的定義:
public abstract class Converter implements Function { protected abstract B doForward(A a); protected abstract A doBackward(B b); //其他略 }
從源碼可以了解到，GUAVA中的Convert可以完成正向轉(zhuǎn)化和逆向轉(zhuǎn)化，繼續(xù)修改我們DTO中轉(zhuǎn)化的這段代碼:
private static class UserInputDTOConvert implements DTOConvert { @Override public User convert(UserInputDTO userInputDTO) { User user = new User(); BeanUtils.copyProperties(userInputDTO,user); return user; } }
修改后:
private static class UserInputDTOConvert extends Converter { @Override protected User doForward(UserInputDTO userInputDTO) { User user = new User(); BeanUtils.copyProperties(userInputDTO,user); return user; } @Override protected UserInputDTO doBackward(User user) { UserInputDTO userInputDTO = new UserInputDTO(); BeanUtils.copyProperties(user,userInputDTO); return userInputDTO; } }
看了這部分代碼以后，你可能會問，那逆向轉(zhuǎn)化會有什么用呢?其實我們有很多小的業(yè)務(wù)需求中，入?yún)⒑统鰠⑹且粯拥模敲次覀冏兛梢暂p松的進(jìn)行轉(zhuǎn)化，我將上邊所提到的UserInputDTO和UserOutputDTO都轉(zhuǎn)成UserDTO展示給大家:
DTO：
public class UserDTO { private String username; private int age; public String getUsername() { return username; } public void setUsername(String username) { this.username = username; } public int getAge() { return age; } public void setAge(int age) { this.age = age; } public User convertToUser(){ UserDTOConvert userDTOConvert = new UserDTOConvert(); User convert = userDTOConvert.convert(this); return convert; } public UserDTO convertFor(User user){ UserDTOConvert userDTOConvert = new UserDTOConvert(); UserDTO convert = userDTOConvert.reverse().convert(user); return convert; } private static class UserDTOConvert extends Converter { @Override protected User doForward(UserDTO userDTO) { User user = new User(); BeanUtils.copyProperties(userDTO,user); return user; } @Override protected UserDTO doBackward(User user) { UserDTO userDTO = new UserDTO(); BeanUtils.copyProperties(user,userDTO); return userDTO; } } }
api:
@PostMapping public UserDTO addUser(UserDTO userDTO){ User user = userDTO.convertToUser(); User saveResultUser = userService.addUser(user); UserDTO result = userDTO.convertFor(saveResultUser); return result; }
當(dāng)然，上述只是表明了轉(zhuǎn)化方向的正向或逆向，很多業(yè)務(wù)需求的出參和入?yún)⒌腄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è)務(wù)異常，這段代碼告訴代碼的調(diào)用者，這個方法不是準(zhǔn)你調(diào)用的，如果你調(diào)用，我就”斷言”你調(diào)用錯誤了。
關(guān)于異常處理的更詳細(xì)介紹，可以參考我之前的文章:如何優(yōu)雅的設(shè)計java異常 ，應(yīng)該可以幫你更好的理解異常。
bean的驗證
如果你認(rèn)為我上邊寫的那個添加用戶api寫的已經(jīng)非常完美了，那只能說明你還不是一個優(yōu)秀的程序員。我們應(yīng)該保證任何數(shù)據(jù)的入?yún)⒌椒椒w內(nèi)都是合法的。
為什么要驗證
很多人會告訴我，如果這些api是提供給前端進(jìn)行調(diào)用的，前端都會進(jìn)行驗證啊，你為什還要驗證?
其實答案是這樣的，我從不相信任何調(diào)用我api或者方法的人，比如前端驗證失敗了，或者某些人通過一些特殊的渠道(比如Charles進(jìn)行抓包),直接將數(shù)據(jù)傳入到我的api，那我仍然進(jìn)行正常的業(yè)務(wù)邏輯處理，那么就有可能產(chǎn)生臟數(shù)據(jù)!
“對于臟數(shù)據(jù)的產(chǎn)生一定是致命”，這句話希望大家牢記在心，再小的臟數(shù)據(jù)也有可能讓你找?guī)讉€通宵!
jsr 303驗證
hibernate提供的jsr 303實現(xiàn)，我覺得目前仍然是很優(yōu)秀的，具體如何使用，我不想講，因為谷歌上你可以搜索出很多答案!
再以上班的api實例進(jìn)行說明，我們現(xiàn)在對DTO數(shù)據(jù)進(jìn)行檢查:
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é)果傳給前端，這種異常應(yīng)該轉(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ù)后，可以拋出一個“帶驗證碼的驗證錯誤異?！?，具體異常設(shè)計可以參考如何優(yōu)雅的設(shè)計java異常
擁抱lombok
上邊的DTO代碼，已經(jīng)讓我看的很累了，我相信讀者也是一樣，看到那么多的Getter和Setter方法，太煩躁了，那時候有什么方法可以簡化這些呢。
請擁抱lombok,它會幫助我們解決一些讓我們很煩躁的問題
去掉Setter和Getter
其實這個標(biāo)題，我不太想說，因為網(wǎng)上太多，但是因為很多人告訴我，他們根本就不知道lombok的存在，所以為了讓讀者更好的學(xué)習(xí)，我愿意寫這樣一個例子：
@Setter @Getter public class UserDTO { @NotNull private String username; @NotNull private int age; public User convertToUser(){ UserDTOConvert userDTOConvert = new UserDTOConvert(); User convert = userDTOConvert.convert(this); return convert; } public UserDTO convertFor(User user){ UserDTOConvert userDTOConvert = new UserDTOConvert(); UserDTO convert = userDTOConvert.reverse().convert(user); return convert; } private static class UserDTOConvert extends Converter { @Override protected User doForward(UserDTO userDTO) { User user = new User(); BeanUtils.copyProperties(userDTO,user); return user; } @Override protected UserDTO doBackward(User user) { throw new AssertionError("不支持逆向轉(zhuǎn)化方法!"); } } }
看到了吧，煩人的Getter和Setter方法已經(jīng)去掉了。
但是上邊的例子根本不足以體現(xiàn)lombok的強(qiáng)大。我希望寫一些網(wǎng)上很難查到，或者很少人進(jìn)行說明的lombok的使用以及在使用時程序語義上的說明。
比如:@Data,@AllArgsConstructor,@NoArgsConstructor..這些我就不進(jìn)行一一說明了，請大家自行查詢資料.
bean中的鏈?zhǔn)斤L(fēng)格
什么是鏈?zhǔn)斤L(fēng)格?我來舉個例子，看下面這個Student的bean:
public class Student { private String name; private int age; public String getName() { return name; } public Student setName(String name) { this.name = name; return this; } public int getAge() { return age; } public Student setAge(int age) { return this; } }
仔細(xì)看一下set方法，這樣的設(shè)置便是chain的style，調(diào)用的時候，可以這樣使用:
Student student = new Student() .setAge(24) .setName("zs");
相信合理使用這樣的鏈?zhǔn)酱a，會更多的程序帶來很好的可讀性，那看一下如果使用lombok進(jìn)行改善呢，請使用 @Accessors(chain = true),看如下代碼:
@Accessors(chain = true) @Setter @Getter public class Student { private String name; private int age; }
這樣就完成了一個對于bean來講很友好的鏈?zhǔn)讲僮鳌?/p>
靜態(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)造方法)要好很多。
當(dāng)然，看過很多源碼以后，我想相信將靜態(tài)構(gòu)造方法ofName換成of會先的更加簡潔:
@Accessors(chain = true) @Setter @Getter @RequiredArgsConstructor(staticName = "of") public class Student { @NonNull private String name; private int age; }
測試代碼:
Student student = Student.of("zs");
當(dāng)然他仍然是支持鏈?zhǔn)秸{(diào)用的:
Student student = Student.of("zs").setAge(24);
這樣來寫代碼，真的很簡潔，并且可讀性很強(qiáng)。
使用builder
Builder模式我不想再多解釋了，讀者可以看一下《Head First》(設(shè)計模式) 的建造者模式。
今天其實要說的是一種變種的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最為底層包裝器進(jìn)行包裝器模式的設(shè)計:
public abstract class FilterRestTemplate implements RestOperations { protected volatile RestTemplate restTemplate; protected FilterRestTemplate(RestTemplate restTemplate){ this.restTemplate = restTemplate; } //實現(xiàn)RestOperations所有的接口 }
然后再由擴(kuò)展類對FilterRestTemplate進(jìn)行包裝擴(kuò)展:
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 { 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所有的接口”,這個操作絕對不是一時半會可以寫完的，當(dāng)時在重構(gòu)之前我?guī)缀鯇懥税雮€小時,如下:
public abstract class FilterRestTemplate implements RestOperations { protected volatile RestTemplate restTemplate; protected FilterRestTemplate(RestTemplate restTemplate) { this.restTemplate = restTemplate; } @Override public T getForObject(String url, Class responseType, Object... uriVariables) throws RestClientException { return restTemplate.getForObject(url,responseType,uriVariables); } @Override public T getForObject(String url, Class responseType, Map uriVariables) throws RestClientException { return restTemplate.getForObject(url,responseType,uriVariables); } @Override public T getForObject(URI url, Class responseType) throws RestClientException { return restTemplate.getForObject(url,responseType); } @Override public ResponseEntity getForEntity(String url, Class 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點前進(jìn)行下單，那么發(fā)貨時間是明天，如果今天下午3點后進(jìn)行下單，那么發(fā)貨時間是后天，如果被確定的時間是周日，那么在此時間上再加1天為發(fā)貨時間。
思考與重構(gòu)
我相信這個需求看似很簡單，無論怎么寫都可以完成。
很多人可能看到這個需求，就動手開始寫Calendar或Date進(jìn)行計算，從而完成需求。
而我給的建議是，仔細(xì)考慮如何寫代碼，然后再去寫，不是說所有的時間操作都用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é)果都當(dāng)做一個變量，最終做一個三目運(yùn)算符的方式進(jìn)行返回，這樣的優(yōu)雅和可讀性顯而易見，當(dāng)然這樣的代碼不是一蹴而就的，我優(yōu)化了3遍產(chǎn)生的以上代碼。讀者可根據(jù)自己的代碼和我寫的代碼進(jìn)行對比。
提高方法
如果你做了3年+的程序員，我相信像如上這樣的需求，你很輕松就能完成，但是如果你想做一個會寫java的程序員，就好好的思考和重構(gòu)代碼吧。
寫代碼就如同寫字一樣，同樣的字，大家都會寫，但是寫出來是否好看就不一定了。如果想把程序?qū)懞茫鸵粩嗟乃伎己椭貥?gòu)，敢于嘗試，敢于創(chuàng)新，不要因循守舊，一定要做一個優(yōu)秀的java程序員。
提高代碼水平最好的方法就是有條理的重構(gòu)!(注意：是有條理的重構(gòu))
設(shè)計模式
設(shè)計模式就是工具，而不是提現(xiàn)你是否是高水平程序員的一個指標(biāo)。
我經(jīng)常會看到某一個程序員興奮的大喊，哪個程序哪個點我用到了設(shè)計模式，寫的多么多么優(yōu)秀，多么多么好。我仔細(xì)去翻閱的時候，卻發(fā)現(xiàn)有很多是過度設(shè)計的。
業(yè)務(wù)驅(qū)動技術(shù) or 技術(shù)驅(qū)動業(yè)務(wù)
業(yè)務(wù)驅(qū)動技術(shù) or 技術(shù)驅(qū)動業(yè)務(wù) ? 其實這是一個一直在爭論的話題，但是很多人不這么認(rèn)為，我覺得就是大家不愿意承認(rèn)罷了。我來和大家大概分析一下作為一個java程序員，我們應(yīng)該如何判斷自己所處于的位置.
業(yè)務(wù)驅(qū)動技術(shù)：如果你所在的項目是一個收益很小或者甚至沒有收益的項目，請不要搞其他創(chuàng)新的東西，不要驅(qū)動業(yè)務(wù)要如何如何做，而是要熟知業(yè)務(wù)現(xiàn)在的痛點是什么?如何才能幫助業(yè)務(wù)盈利或者讓項目更好，更順利的進(jìn)行。
技術(shù)驅(qū)動業(yè)務(wù)：如果你所在的項目是一個很牛的項目，比如淘寶這類的項目，我可以在滿足業(yè)務(wù)需求的情況下，和業(yè)務(wù)溝通，使用什么樣的技術(shù)能更好的幫助業(yè)務(wù)創(chuàng)造收益，比如說下單的時候要進(jìn)隊列，可能幾分鐘之后訂單狀態(tài)才能處理完成，但是會讓用戶有更流暢的體驗，賺取更多的訪問流量，那么我相信業(yè)務(wù)愿意被技術(shù)驅(qū)動，會同意訂單的延遲問題，這樣便是技術(shù)驅(qū)動業(yè)務(wù)。
我相信大部分人還都處于業(yè)務(wù)驅(qū)動技術(shù)的方向吧。
所以你既然不能驅(qū)動業(yè)務(wù)，那就請擁抱業(yè)務(wù)變化吧。
代碼設(shè)計
一直在做java后端的項目，經(jīng)常會有一些變動，我相信大家也都遇到過。
比如當(dāng)我們寫一段代碼的時候，我們考慮將需求映射成代碼的狀態(tài)模式，突然有一天，狀態(tài)模式里邊又添加了很多行為變化的東西，這時候你就撓頭了，你硬生生的將狀態(tài)模式中添加過多行為和變化。
慢慢的你會發(fā)現(xiàn)這些狀態(tài)模式，其實更像是一簇算法，應(yīng)該使用策略模式，這時你應(yīng)該已經(jīng)暈頭轉(zhuǎn)向了。
說了這么多，我的意思是，只要你覺得合理，就請將狀態(tài)模式改為策略模式吧，所有的模式并不是憑空想象出來的，都是基于重構(gòu)。
java編程中沒有銀彈，請擁抱業(yè)務(wù)變化，一直思考重構(gòu)，你就有一個更好的代碼設(shè)計!
你真的優(yōu)秀嗎?
真不好意思，我取了一個這么無聊的標(biāo)題。
國外流行一種編程方式，叫做結(jié)對編程，我相信國內(nèi)很多公司都沒有這么做，我就不在講述結(jié)對編程帶來的好處了，其實就是一邊code review，一邊互相提高的一個過程。既然做不到這個，那如何讓自己活在自己的世界中不斷提高呢?
“平時開發(fā)的時候，做出的代碼總認(rèn)為是正確的，而且寫法是完美的?！?，我相信這是大部分人的心聲，還回到剛剛的問題，如何在自己的世界中不斷提高呢?
答案就是:
多看成熟框架的源碼
多回頭看自己的代碼
勤于重構(gòu)
你真的優(yōu)秀嗎? 如果你每周都完成了學(xué)習(xí)源碼，回頭看自己代碼，然后勤于重構(gòu)，我認(rèn)為你就真的很優(yōu)秀了。
即使也許你只是剛剛?cè)腴T，但是一直堅持，你就是一個真的會寫java代碼的程序員了。
技能
UML
不想多討論UML相關(guān)的知識，但是我覺得你如果真的會寫java，請先學(xué)會表達(dá)自己，UML就是你說話的語言，做一名優(yōu)秀的java程序員，請至少學(xué)會這兩種UML圖：
類圖
時序圖
clean code
我認(rèn)為保持代碼的簡潔和可讀性是代碼的最基本保證，如果有一天為了程序的效率而降低了這兩點，我認(rèn)為是可以諒解的，除此之外，沒有任何理由可以讓你任意揮霍你的代碼。
讀者可以看一下Robert C. Martin出版的《Clean Code》(代碼整潔之道) 這本書
可以參考美團(tuán)文章聊聊clean code
也可以看一下阿里的Java編碼規(guī)范
無論如何，請保持你的代碼的整潔。
linux 基礎(chǔ)命令
這點其實和會寫java沒有關(guān)系，但是linux很多時候確實承載運(yùn)行java的容器，請學(xué)好linux的基礎(chǔ)命令。
參考鳥哥的《Linux私房菜》
總結(jié)
java是一個大體系，今天討論并未涉及框架和架構(gòu)相關(guān)知識，只是討論如何寫好代碼。
本文從寫java程序的小方面一直寫到大方面，來闡述了如何才能寫好java程序，并告訴讀者們?nèi)绾尾拍芴岣咦陨淼木幋a水平。
我希望看到這篇文章的各位都能做一個優(yōu)秀的java程序員。
網(wǎng)站欄目：老生常談：你真的會寫Java嗎？
網(wǎng)頁地址：http://ef60e0e.cn/article/posged.html
