Java編程風格探討

作者：admin

最近Stephan Schmidt在部落格中發表了題為《下一代Java編程風格》的文章，闡述了他眼中Java編程風格的改變，以及未來的走向：許多公司和開發人員正在從Java轉向其他程式設計語言：Ruby、Python、Groovy、Erlang或Scala等等。不過你可能做不到這一 點。即便如此，你也可以改變你的編程風格，擷取這些新語言的優勢。事實上，在過去的15年中，Java編程風格也已經有明顯變化了。

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

1. 儘可能地標註final：讓所有東西不可變，把變數標為final可以阻止改變它的值。很多時候，重新為變數賦值會引入bug，你應該使用新的變數。除此之外，final可以提高代碼的可讀性。我針對這個話題還寫過一篇文章：《Java中所有變數都應該是final的》
2. 沒有setter：許多Java程式員會自然而然地為類中所有的欄位加上setter。思考一下，真的每個欄位都需要修改嗎？更好的方法是建立包含改變後狀態的新對象。此外，也試著去除getter，我們應該遵循“Tell, don’t ask”的思想。
3. 避免使用迴圈來操作List：從函數式編程那裡獲得的經驗，迴圈並不是進行集合操作最好方法。例如，我們可以使用Google Collections提供的過濾功能。

   Predicate canDrinkBeer = new Predicate() {     public boolean apply(HasAge hasAge) {         return hasAge.isOlderThan( 16 );    }};List<Person> beerDrinkers = filter(persons, canDrinkBeer);

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

   public int add(int a, int b) { return a + b; }

5. 使用大量介面：領域驅動設計已經大行其道，一個應該拆分為多種“角色”，即實現多種介面，提高複用程度。方法應該面向“角色”，而不是面向特定的類。我在《不要在Java中使用String》一文中討論了更多這方面的內容。
6. 使用Erlang風格的並發：Java的並發特性（如lock和synchronized）過於低端，難以使用。Erlang風格的並發是一種更好的做法。Java平台上已經有了Akka和Actorom。此外，也可以使用java.util.concurrent中的Join/Fork和資料結構進行編程。
7. 使用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);            }        });

8. 避免在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中優雅地體現出來了。

本文引用地址

http://java.csdn.net/index.php/2009/08/19/%e7%83%ad%e7%82%b9%e8%ae%a8%e8%ae%ba%ef%bc%9ajava%e7%bc%96%e7%a8%8b%e9%a3%8e%e6%a0%bc%e7%9a%84%e6%94%b9%e5%8f%98/