Stephan在文章中提出了以下幾點：
盡可能地標注final：讓所有東西不可變，把變量標為final可以阻止改變它的值。很多時候，重新為變量賦值會引入bug，你應該使用新的變量。除此之外，final可以提高代碼的可讀性。我針對這個話題還寫過一篇文章：《Java中所有變量都應該是final的》
沒有setter：許多Java程序員會自然而然地為類中所有的字段加上setter。思考一下，真的每個字段都需要修改嗎?更好的方法是創建包含改變后狀態的新對象。此外，也試著去除getter，我們應該遵循“Tell, don’t ask”的思想。
避免使用循環來操作List：從函數式編程那里獲得的經驗，循環并不是進行集合操作最好方法。例如，我們可以使用Google Collections提供的過濾功能。
Predicate canDrinkBeer = new Predicate() { public boolean apply(HasAge hasAge) { return hasAge.isOlderThan( 16 ); } }; List beerDrinkers = filter(persons, canDrinkBeer); |
使用單行代碼：Java是一門繁雜(noisy)的語言，我們應該編寫更精確的代碼。嘗試將代碼寫為一行。例如：
public int add(int a, int b) { return a + b; } |
使用大量接口：領域驅動設計已經大行其道，一個應該拆分為多種“角色”，即實現多種接口，提高復用程度。方法應該面向“角色”，而不是面向特定的類。我在《不要在Java中使用String》一文中討論了更多這方面的內容。
使用Erlang風格的并發：Java的并發特性(如lock和synchronized)過于低端，難以使用。Erlang風格的并發是一種更好的做法。Java平臺上已經有了Akka和Actorom。此外，也可以使用java.util.concurrent中的Join/Fork和數據結構進行編程。
使用Fluent Interface：Fluent Interface可以使代碼更短，更容易編寫。Google Collections中的MapMaker是個不錯的示例：
ConcurrentMap graphs = new MapMaker() .concurrencyLevel(32) .softKeys() .weakValues() .expiration(30, TimeUnit.MINUTES) .makeComputingMap( new Function() { public Graph apply(Key key) { return createExpensiveGraph(key); } }); |
避免在DTO中創建getter和setter：如果你擁有簡單的DTO(Data Transfer Object)，不要耗費精力去編寫getter和setter，直接使用公開的字段吧。不過在你無法完全控制代碼的使用情況時，還是小心為上。
這篇文章發表之后，有許多人發表了不同的看法。其中Cedric Otaku發表了文章《下一代Java與現在差不多》予以回應，其中反對了Stephan提出的大部分觀點。
盡可能final：太多final會降低代碼的可讀性，它無法代碼額外的好處。我已經不記得上次因為重新給變量賦值而造成錯誤是什么時候了。值得一提的是，在字段以外的成員上標記final違反了Google的風格指南。
避免setter：看上去不錯，不過這不現實。有些時候你不愿把所有的參數都通過構造函數傳入。此外，如果使用對象池的時候，可變的對象會讓編程更為方便。Stephan不是第一個提出要將訪問器(accessor)從OO編程中移除的人，不過這個說法很明顯不可行。
避免循環：Java并不適合函數式編程風格，所以我認為使用Predicate的代碼反而難以讀懂。我估計大部分的Java程序員會同意我的觀點，即使他們已經熟悉了閉包風格。
單行代碼：這要視情況而定。并引入臨時變量把一個表達式拆開可以提高代碼可讀性，也容易為其設置斷點。
使用接口：不錯的建議，但也不能過火。過去我也爭論過類似的話題，不過引入太多接口會導致細小類型的爆炸，使你高端的類型意圖變得模糊。
Erlang風格并行：重申一點，使用Java設計以外的編程風格是危險的做法。java.util.concurrent中包含了非常有用的功能，我遇到過不少基于這些元素的Java抽象，它們要優于Erlang風格的actor架構。
Fluent Interface：這個建議比較有趣，它與Stephan提出的另一個建議“避免setter”相違背。Fluent Interface制式setter的另一種形式，不是嗎?
使用公有字段：不，千萬別這么做。你不會因為加了訪問器而后悔，但是我能保證你會因為一時偷懶，使用了公有字段而后悔莫及。
在Cedric的文章之后，Stephan又對他的說法進行了補充：
沒有setter并不代表你不能修改這個對象，我只是說純粹的setter不是面向對象的思維方式。例如，你覺得stop()和setStop(true)哪個更好一些?
(針對Predicate代碼不易讀)我認為你的假設有誤。循環是“程序化”的代碼，而Predicate是經過封裝的，可以重用的，易于理解的“對象”。這里并沒有函數式編程，這里是純粹的OO – 我提起FP只是因為我從那里“引入”了這個方式。
還有許多人對Stephon和Cedric的文章發表了評論，例如有人支持Stephan的觀點，認為final的可以更好的表示出代碼的意圖。甚至有人提出：
更簡單的解決方案是使用Scala :) – 不可變的狀態、統一訪問原則(字段、屬性、方法看上去一樣)、單行代碼、使用monads或函數來替代循環……這些特性都已經在Scala中優雅地體現出來了。
您的Java編程風格是什么樣的，和過去相比有什么改變嗎?
新聞熱點
疑難解答
圖片精選
