最近Stephan Schmidt在博客中發(fā)表了題為《下一代Java編程風(fēng)格》的文章，闡述了他眼中Java編程風(fēng)格的改變，以及未來的走向：許多公司和開發(fā)人員正在從Java轉(zhuǎn)向其他編程語言：Ruby、Python、Grrovy、Erlang或Scala等等。不過你可能做不到這一 點(diǎn)。即便如此，你也可以改變你的編程風(fēng)格，獲取這些新語言的優(yōu)勢。事實(shí)上，在過去的15年中，Java編程風(fēng)格也已經(jīng)有明顯變化了。
Stephan在文章中提出了以下幾點(diǎn)：
- 盡可能地標(biāo)注final：讓所有東西不可變，把變量標(biāo)為final可以阻止改變它的值。很多時(shí)候，重新為變量賦值會引入bug，你應(yīng)該使用新的變量。除此之外，final可以提高代碼的可讀性。我針對這個(gè)話題還寫過一篇文章：《Java中所有變量都應(yīng)該是final的》
- 沒有setter：許多Java程序員會自然而然地為類中所有的字段加上setter。思考一下，真的每個(gè)字段都需要修改嗎？更好的方法是創(chuàng)建包含改變后狀態(tài)的新對象。此外，也試著去除getter，我們應(yīng)該遵循“Tell, don’t ask”的思想。
- 避免使用循環(huán)來操作List：從函數(shù)式編程那里獲得的經(jīng)驗(yàn)，循環(huán)并不是進(jìn)行集合操作最好方法。例如，我們可以使用Google Collections提供的過濾功能。
4. Predicate canDrinkBeer = new Predicate() {5. public boolean apply(HasAge hasAge) {6. return hasAge.isOlderThan( 16 );
7. }
8. };
9.
List<Person> beerDrinkers = filter(persons, canDrinkBeer);
- 使用單行代碼：Java是一門繁雜（noisy）的語言，我們應(yīng)該編寫更精確的代碼。嘗試將代碼寫為一行。例如：
public int add(int a, int b) { return a + b; }
- 使用大量接口：領(lǐng)域驅(qū)動設(shè)計(jì)已經(jīng)大行其道，一個(gè)應(yīng)該拆分為多種“角色”，即實(shí)現(xiàn)多種接口，提高復(fù)用程度。方法應(yīng)該面向“角色”，而不是面向特定的類。我在《不要在Java中使用String》一文中討論了更多這方面的內(nèi)容。
- 使用Erlang風(fēng)格的并發(fā)：Java的并發(fā)特性（如lock和synchronized）過于低端，難以使用。Erlang風(fēng)格的并發(fā)是一種更好的做法。Java平臺上已經(jīng)有了Akka和Actorom。此外，也可以使用java.util.concurrent中的Join/Fork和數(shù)據(jù)結(jié)構(gòu)進(jìn)行編程。
- 使用Fluent Interface：Fluent Interface可以使代碼更短，更容易編寫。Google Collections中的MapMaker是個(gè)不錯(cuò)的示例：
14. ConcurrentMap graphs = new MapMaker()
15. .concurrencyLevel(32)
16. .softKeys()
17. .weakValues()
18. .expiration(30, TimeUnit.MINUTES)
19. .makeComputingMap(
20. new Function() {21. public Graph apply(Key key) {22. return createExpensiveGraph(key);
23. }
});
- 避免在DTO中創(chuàng)建getter和setter：如果你擁有簡單的DTO（Data Transfer Object），不要耗費(fèi)精力去編寫getter和setter，直接使用公開的字段吧。不過在你無法完全控制代碼的使用情況時(shí)，還是小心為上。
這篇文章發(fā)表之后，有許多人發(fā)表了不同的看法。其中Cedric Otaku發(fā)表了文章《下一代Java與現(xiàn)在差不多》予以回應(yīng)，其中反對了Stephan提出的大部分觀點(diǎn)。
- 盡可能final：太多final會降低代碼的可讀性，它無法代碼額外的好處。我已經(jīng)不記得上次因?yàn)橹匦陆o變量賦值而造成錯(cuò)誤是什么時(shí)候了。值得一提的是，在字段以外的成員上標(biāo)記final違反了Google的風(fēng)格指南。
- 避免setter：看上去不錯(cuò)，不過這不現(xiàn)實(shí)。有些時(shí)候你不愿把所有的參數(shù)都通過構(gòu)造函數(shù)傳入。此外，如果使用對象池的時(shí)候，可變的對象會讓編程更為方便。Stephan不是第一個(gè)提出要將訪問器（accessor）從OO編程中移除的人，不過這個(gè)說法很明顯不可行。
- 避免循環(huán)：Java并不適合函數(shù)式編程風(fēng)格，所以我認(rèn)為使用Predicate的代碼反而難以讀懂。我估計(jì)大部分的Java程序員會同意我的觀點(diǎn)，即使他們已經(jīng)熟悉了閉包風(fēng)格。
- 單行代碼：這要視情況而定。并引入臨時(shí)變量把一個(gè)表達(dá)式拆開可以提高代碼可讀性，也容易為其設(shè)置斷點(diǎn)。
- 使用接口：不錯(cuò)的建議，但也不能過火。過去我也爭論過類似的話題，不過引入太多接口會導(dǎo)致細(xì)小類型的爆炸，使你高端的類型意圖變得模糊。
- Erlang風(fēng)格并行：重申一點(diǎn)，使用Java設(shè)計(jì)以外的編程風(fēng)格是危險(xiǎn)的做法。java.util.concurrent中包含了非常有用的功能，我遇到過不少基于這些元素的Java抽象，它們要優(yōu)于Erlang風(fēng)格的actor架構(gòu)。
- Fluent Interface：這個(gè)建議比較有趣，它與Stephan提出的另一個(gè)建議“避免setter”相違背。Fluent Interface制式setter的另一種形式，不是嗎？
- 使用公有字段：不，千萬別這么做。你不會因?yàn)榧恿嗽L問器而后悔，但是我能保證你會因?yàn)橐粫r(shí)偷懶，使用了公有字段而后悔莫及。
在Cedric的文章之后，Stephan又對他的說法進(jìn)行了補(bǔ)充：
沒有setter并不代表你不能修改這個(gè)對象，我只是說純粹的setter不是面向?qū)ο蟮乃季S方式。例如，你覺得stop()和setStop(true)哪個(gè)更好一些？
（針對Predicate代碼不易讀）我認(rèn)為你的假設(shè)有誤。循環(huán)是“程序化”的代碼，而Predicate是經(jīng)過封裝的，可以重用的，易于理解的“對象”。這里并沒有函數(shù)式編程，這里是純粹的OO – 我提起FP只是因?yàn)槲覐哪抢?span lang="EN-US">“引入”了這個(gè)方式。
還有許多人對Stephon和Cedric的文章發(fā)表了評論，例如有人支持Stephan的觀點(diǎn)，認(rèn)為final的可以更好的表示出代碼的意圖。甚至有人提出：
更簡單的解決方案是使用Scala :) – 不可變的狀態(tài)、統(tǒng)一訪問原則（字段、屬性、方法看上去一樣）、單行代碼、使用monads或函數(shù)來替代循環(huán)……這些特性都已經(jīng)在Scala中優(yōu)雅地體現(xiàn)出來了。
您的Java編程風(fēng)格是什么樣的，和過去相比有什么改變嗎？