java编程风格的改变（转载于infoq）

 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中优雅地体现出来了。