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