10 个 Java 编码中微妙的最佳实践

shinepaopao

浏览: 145725 次

最近访客更多访客>>

dong717

BobWaters

lxheyu

blue4wang

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

Java

java c 数据结构多线程

1.牢记C++的析构函数

　　还记得C++中的析构函数吗？不记得了？或许你真的很幸运，因为你再也不必为删除对象后，没有

及时释放内存而造成内存泄露进行调试了。我们真的应该感谢Sun和Oracle实现垃圾回收机制。

　　尽管如此，对于我们来说，析构函数仍然有一个很有趣的特点。它常常会让我们对以和分配内存相反

的顺序释放内存的工作模式感到容易理解。同样，在JAVA代码中，当你处理如下类析构函数语法的时候，

也要把这个特性牢记在心：

当使用@Before和@After但与注解时

当分配和释放JDBC资源时

当调用父类的方法时

也有其他不同的使用案例。这有一个显示如何实现事件监听的实例：

01
@Override

02

public void beforeEvent(EventContext e) {

03

  super.beforeEvent(e);

04

  // Super code before my code

05
}

06
 
07
@Override

08

public void afterEvent(EventContext e) {

09

  // Super code after my code

10

  super.afterEvent(e);

11
}

　　另外一个哲学家用餐的问题，显示了这有多么的重要。

　　关于哲学家用餐的问题，请查看链接：http://adit.io/posts/2013-05-11-The-Dining-Philos

ophers-Problem-With-Ron-Swanson.html

　　法则：无论何时，当你使用before/after, allocate/free, take/return语法实现逻辑时，仔细想想是

否需要反序的使用after/free/return操作。

2. 不要相信你早期的SPI演进判断

为使用者提供SPI可以很容易让他们注入自定义行为到你的库/代码。当心你的SPI演进判断可能会迷惑你，

让你认为(不)需要附加的参数。当然，不应该过早的添加功能。但是一旦你发布了SPI，一旦你决定遵循

语义版本，当你发现你可能在某些情况下需要另外一个参数时，你将真的后悔为SPI添加了一个愚蠢的单

参数方法：

1

interface EventListener {

2

  // Bad

3

  void message(String message);

4
}

如果你也需要消息ID和消息源，怎么办？对于上面的类型，API演进将会阻碍你添加参数。当然，有了

Java8，你可以添加一个defender方法，“防御”你早期糟糕的设计决策：

01

interface EventListener {

02

  // Bad

03

  default void message(String message) {

04

    message(message, null, null);

05

  }

06

  // Better?

07

  void message(

08

    String message,

09

    Integer id,

10

    MessageSource source

11

  );

12
}

注意很不幸defender方法不能为final。

但是比起用数十个方法污染你的SPI，使用一个上下文对象（或参数对象）好很多。

 
01

interface MessageContext {

02

  String message();

03

  Integer id();

04

  MessageSource source();

05
}

06
 
07

interface EventListener {

08

  // Awesome!

09

  void message(MessageContext context);

10
}

比起EventListner SPI你可以更容易演进MessageContext API，因为很少用户会实现它。

规则: 无论何时你指定SPI的时候，考虑使用上下文/参数对象，而不要编写固定参数数量的方法。

备注: 使用特定的MessageResult类型传递结果也是一个好的想法，该类型可以通过构造器API构建。

这将会为你的SPI提供更多的SPI演进灵活性。

3.避免使用匿名，局部或内部类

Swing程序员通常只要按几下快捷键即可生成成百上千的匿名类。在多数情况下，只要遵循接口、不违法SPI子

类型的生命周期(SPI subtype lifecycle)，这样做也无妨。

但是不要因为一个简单的原因——它们会保存对外部类的引用，就频繁的使用匿名、局部或者内部类。因为无论

它们走到哪，外部类就得跟到哪。例如，在局部类的域外操作不当的话，那么整个对象图就会发生微妙的变化从

而可能引起内存泄露。

规则：在编写匿名、局部或内部类前请三思能否将它转化为静态的或普通的顶级类，从而避免方法将它们的对象

返回到更外层的域中。

注意：使用双层花括号来初始化简单对象：

1

new HashMap<string, string="" style="margin: 0px; padding: 0px; word-wrap: break-word;">() {{

2

  put("1", "a");

3

  put("2", "b");

4
}}

这个方法利用了 JLS §8.6规范里描述的实例初始化方法(initializer)。表面上看起来不错，但实际上不提倡这种

做法。因为要是使用完全独立的HashMap对象，那么实例就不会一直保存着外部对象的引用。此外，这也会让

类加载器管理更多的类。

4. 现在就开始编写SAM！

Java8的脚步近了。伴随着Java8带来了lambda表达式，无论你是否喜欢。尽管你的API使用者可能会喜欢，

但是你最好确保他们可以尽可能经常的使用。因此除非你的API接收简单的“标量”类型，比如int、long、

String 、Date，否则让你的API尽可能经常的接收SAM。

什么是SAM？SAM是单一抽象方法[类型]。也称为函数接口，很快被注释为@FunctionalInterface。这与规

则2很配，EventListener实际上就是一个SAM。最好的SAM只有一个参数，因为这将会进一步简化lambda表

达式的编写。设想编写

1
listeners.add(c -> System.out.println(c.message()));

替代

1

listeners.add(new EventListener() {

2

  @Override

3

  public void message(MessageContext c) {

4

    System.out.println(c.message()));

5

  }

6
});

设想以SAM的方式用jOOX处理XML：

1
$(document)

2

  // Find elements with an ID

3

  .find(c -> $(c).id() != null)

4

  // Find their child elements

5

  .children(c -> $(c).tag().equals("order"))

6

  // Print all matches

7

  .each(c -> System.out.println($(c)))

规则：对你的API使用者好一点儿，从现在开始编写SAM/函数接口。

备注：有许多关于Java8 lambda表达式和改善的Collections API的有趣的博客：

5.避免让方法返回null

我曾写过1、2篇关于java NULLs的文章，也讲解过Java8中引入新的Optional类。从学术或实用的角

度来看，这些话题还是比较有趣的。

尽管现阶段Null和NullPointerException依然是Java的硬伤，但是你仍可以设计出不会出现任何问题的

API。在设计API时，应当尽可能的避免让方法返回null，因为你的用户可能会链式调用方法：

1
initialise(someArgument).calculate(data).dispatch();

从上面代码中可看出，任何一个方法都不应返回null。实际上，在通常情况下使用null会被认为相当的异类。像 jQuery或 jOOX这样的库在可迭代的对象上已完全的摒弃了null。

Null通常用在延迟初始化中。在许多情况下，在不严重影响性能的条件下，延迟初始化也应该被避免。实际

上，如果涉及的数据结构过于庞大，那么就要慎用延迟初始化。

规则：无论何时方法都应避免返回null。null仅用来表示“未初始化”或“不存在”的语义。

6.设计API时永远不要返回空(null)数组或List

尽管在一些情况下方法返回值为null是可以的，但是绝不要返回空数组或空集合！请看 java.io.File.list()

方法，它是这样设计的：

此方法会返回一个指定目录下所有文件或目录的字符串数组。如果目录为空(empty)那么返回的数组也为空

(empty)。如果指定的路径不存在或发生I/O错误，则返回null。

因此，这个方法通常要这样使用：

01

File directory = // ...

02
 
03

if (directory.isDirectory()) {

04

  String[] list = directory.list();

05
 
06

  if (list != null) {

07

    for (String file : list) {

08

      // ...

09

    }

10

  }

11
}

大家觉得null检查有必要吗？大多数I/O操作会产生IOExceptions，但这个方法却只返回了null。Null是无

法存放I/O错误信息的。因此这样的设计，有以下3方面的不足：

Null无助于发现错误
Null无法表明I/O错误是由File实例所对应的路径不正确引起的
每个人都可能会忘记判断null情况

以集合的思维来看待问题的话，那么空的(empty)的数组或集合就是对“不存在”的最佳实现。返回空(null)

数组或集合几乎是无任何实际意义的，除非用于延迟初始化。

规则：返回的数组或集合不应为null。

7. 避免状态，使用函数

HTTP的好处是无状态。所有相关的状态在每次请求和响应中转移。这是REST命名的本质：表征状态转移。

在Java中这样做也很赞。当方法接收状态参数对象的时候从规则2的角度想想这件事。如果状态通过这种对

象转移，而不是从外边操作状态，那么事情将会更简单。以JDBC为例。下述例子从一个存储的程序中读取

一个光标。

01
CallableStatement s =

02

  connection.prepareCall("{ ? = ... }");

03
 
04
// Verbose manipulation of statement state:

05

s.registerOutParameter(1, cursor);

06

s.setString(2, "abc");

07
s.execute();

08

ResultSet rs = s.getObject(1);

09
 
10
// Verbose manipulation of result set state:

11
rs.next();

12
rs.next();

这使得JDBC API如此的古怪。每个对象都是有状态的，难以操作。具体的说，有两个主要的问题：

在多线程环境很难正确的处理有状态的API
很难使有状态的资源全局可用，因为状态没有被描述

规则：更多的以函数风格实现。通过方法参数转移状态。极少操作对象状态。

8. 短路式 equals()

这是一个比较容易操作的方法。在比较复杂的对象系统中，你可以获得显著的性能提升，只要你在所有对象的

equals()方法中首先进行相等判断:

1
@Override

2

public boolean equals(Object other) {

3

  if (this == other) return true;

4

  // 其它相等判断逻辑...

5
}

注意，其它短路式检查可能涉及到null值检查，所以也应当加进去:

1
@Override

2

public boolean equals(Object other) {

3

  if (this == other) return true;

4

  if (other == null) return false;

5

  // Rest of equality logic...

6
}

规则: 在你所有的equals()方法中使用短路来提升性能。

9. 尽量使方法默认为final

有些人可能不同意这一条，因为使方法默认为final与Java开发者的习惯相违背。但是如果你对代码有完全的

掌控，那么使方法默认为final是肯定没错的：

如果你确实需要覆盖（override）一个方法（你真的需要？），你仍然可以移除final关键字
你将永远不会意外地覆盖（override）任何方法

这特别适用于静态方法，在这种情况下“覆盖”（实际上是遮蔽）几乎不起作用。我最近在Apache Tika中遇

到了一个很糟糕的遮蔽静态方法的例子。考虑：

TikaInputStream扩展了TaggedInputStream，以一种相对不同的实现遮蔽了它的静态get()方法。

与常规方法不同，静态方法不能互相覆盖，因为调用的地方在编译时就绑定了静态方法调用。如果你不走运，

你可能会意外获得错误的方法。

规则：如果你完全掌控你的API，那么使尽可能多的方法默认为final。

10. 避免方法(T…)签名

在特殊场合下使用“accept-all”变量参数方法接收一个Object...参数就没有错的：

1

void acceptAll(Object... all);

编写这样的方法为Java生态系统带来一点儿JavaScript的感觉。当然你可能想要根据真实的情形限制实际的

类型，比如String...。因为你不想要限制太多，你可能会认为用泛型T取代Object是一个好想法：

1

void acceptAll(T... all);

但是不是。T总是会被推断为Object。实际上你可能仅仅认为上述方法中不能使用泛型。更重要的是你可能

认为你可以重载上述方法，但是你不能：

1

void acceptAll(T... all);

2

void acceptAll(String message, T... all);

这看起来好像你可以可选地传递一个String消息到方法。但是这个调用会发生什么呢？

1

acceptAll("Message", 123, "abc");

编译器将T推断为>，这将会使调用不明确！所以无论何时你有一个“accept-all”签名（即使是泛型），你将永

远不能类型安全地重载它。API使用者可能仅仅在走运的时候才会让编译器“偶然地”选择“正确的”限定最多的方

法。但是也可能使用accept-all方法或者无法调用任何方法。

规则: 如果可能，避免“accept-all”签名。如果不能，不要重载这样的方法。

结论

Java是一个野兽。不像其它更理想主义的语言，它慢慢地演进为今天的样子。这可能是一件好事，因为以Java

的开发速度就已经有成百上千个警告，而且这些警告只能通过多年的经验去把握。

敬请期待更多关于这个主题的前十名列表！

英文原文：10 Subtle Best Practices when Coding Java

2
顶

4
踩

分享到：

常用的主机监控Shell脚本 | Linux防火墙设置

2013-08-30 23:42
浏览 1492
评论(0)
分类:编程语言
查看更多

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论