Stephan在文章中提出了以下幾點：

　　盡可能地標注final：讓所有東西不可變，把變量標為final可以阻止改變它的值。很多時候，重新為變量賦值會引入bug，你應該使用新的變量。除此之外，final可以提高代碼的可讀性。我針對這個話題還寫過一篇文章：《Java中所有變量都應該是final的》

　　沒有setter：許多Java程序員會自然而然地為類中所有的字段加上setter。思考一下，真的每個字段都需要修改嗎?更好的方法是創(chuàng)建包含改變后狀態(tài)的新對象。此外，也試著去除getter，我們應該遵循“Tell, don’t ask”的思想。

　　避免使用循環(huán)來操作List：從函數(shù)式編程那里獲得的經(jīng)驗，循環(huán)并不是進行集合操作最好方法。例如，我們可以使用Google Collections提供的過濾功能。

　　使用單行代碼：Java是一門繁雜(noisy)的語言，我們應該編寫更精確的代碼。嘗試將代碼寫為一行。例如：

　　使用大量接口：領(lǐng)域驅(qū)動設計已經(jīng)大行其道，一個應該拆分為多種“角色”，即實現(xiàn)多種接口，提高復用程度。方法應該面向“角色”，而不是面向特定的類。我在《不要在Java中使用String》一文中討論了更多這方面的內(nèi)容。

　　使用Erlang風格的并發(fā)：Java的并發(fā)特性(如lock和synchronized)過于低端，難以使用。Erlang風格的并發(fā)是一種更好的做法。Java平臺上已經(jīng)有了Akka和Actorom。此外，也可以使用java.util.concurrent中的Join/Fork和數(shù)據(jù)結(jié)構(gòu)進行編程。

　　使用Fluent Interface：Fluent Interface可以使代碼更短，更容易編寫。Google Collections中的MapMaker是個不錯的示例：

　　避免在DTO中創(chuàng)建getter和setter：如果你擁有簡單的DTO(Data Transfer Object)，不要耗費精力去編寫getter和setter，直接使用公開的字段吧。不過在你無法完全控制代碼的使用情況時，還是小心為上。

　　這篇文章發(fā)表之后，有許多人發(fā)表了不同的看法。其中Cedric Otaku發(fā)表了文章《下一代Java與現(xiàn)在差不多》予以回應，其中反對了Stephan提出的大部分觀點。

　　盡可能final：太多final會降低代碼的可讀性，它無法代碼額外的好處。我已經(jīng)不記得上次因為重新給變量賦值而造成錯誤是什么時候了。值得一提的是，在字段以外的成員上標記final違反了Google的風格指南。

　　避免setter：看上去不錯，不過這不現(xiàn)實。有些時候你不愿把所有的參數(shù)都通過構(gòu)造函數(shù)傳入。此外，如果使用對象池的時候，可變的對象會讓編程更為方便。Stephan不是第一個提出要將訪問器(accessor)從OO編程中移除的人，不過這個說法很明顯不可行。

　　避免循環(huán)：Java并不適合函數(shù)式編程風格，所以我認為使用Predicate的代碼反而難以讀懂。我估計大部分的Java程序員會同意我的觀點，即使他們已經(jīng)熟悉了閉包風格。

　　單行代碼：這要視情況而定。并引入臨時變量把一個表達式拆開可以提高代碼可讀性，也容易為其設置斷點。

　　使用接口：不錯的建議，但也不能過火。過去我也爭論過類似的話題，不過引入太多接口會導致細小類型的爆炸，使你高端的類型意圖變得模糊。

　　Erlang風格并行：重申一點，使用Java設計以外的編程風格是危險的做法。java.util.concurrent中包含了非常有用的功能，我遇到過不少基于這些元素的Java抽象，它們要優(yōu)于Erlang風格的actor架構(gòu)。

　　Fluent Interface：這個建議比較有趣，它與Stephan提出的另一個建議“避免setter”相違背。Fluent Interface制式setter的另一種形式，不是嗎?

　　使用公有字段：不，千萬別這么做。你不會因為加了訪問器而后悔，但是我能保證你會因為一時偷懶，使用了公有字段而后悔莫及。

　　在Cedric的文章之后，Stephan又對他的說法進行了補充：

　　沒有setter并不代表你不能修改這個對象，我只是說純粹的setter不是面向?qū)ο蟮乃季S方式。例如，你覺得stop()和setStop(true)哪個更好一些?

　　(針對Predicate代碼不易讀)我認為你的假設有誤。循環(huán)是“程序化”的代碼，而Predicate是經(jīng)過封裝的，可以重用的，易于理解的“對象”。這里并沒有函數(shù)式編程，這里是純粹的OO – 我提起FP只是因為我從那里“引入”了這個方式。

　　還有許多人對Stephon和Cedric的文章發(fā)表了評論，例如有人支持Stephan的觀點，認為final的可以更好的表示出代碼的意圖。甚至有人提出：

　　更簡單的解決方案是使用Scala :) – 不可變的狀態(tài)、統(tǒng)一訪問原則(字段、屬性、方法看上去一樣)、單行代碼、使用monads或函數(shù)來替代循環(huán)……這些特性都已經(jīng)在Scala中優(yōu)雅地體現(xiàn)出來了。

　　您的Java編程風格是什么樣的，和過去相比有什么改變嗎?