最近 Stephan Schmidt 在博客中发表了题为《下一代 Java 编程风格》的文章，阐述了他眼中 Java 编程风格的改变，以及未来的走向：
许多公司和开发人员正在从 Java 转向其他编程语言：Ruby、Python、Grrovy、Erlang 或 Scala 等等。不过你可能做不到这一点。即便如此，你也可以改变你的编程风格，获取这些新语言的优势。事实上，在过去的 15 年中，Java 编程风格也已经有明显变化了。
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 中使用 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);
}
});复制代码
这篇文章发表之后，有许多人发表了不同的看法。其中 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 编程风格是什么样的，和过去相比有什么改变吗？
评论