10个精妙的Java编码最佳实践

这是一个比Josh Bloch的Effective
Java规则更精妙的10条Java编码实践的列表。和Josh
Bloch的列表容易学习并且关注日常情况相比，这个列表将包含涉及API/SPI设计中不常见的情况，可能有很大影响。

我在编写和维护jOOQ(Java中内部DSL建模的SQL)时遇到过这些。作为一个内部DSL，jOOQ最大限度的挑战了Java的编译器和泛型，把泛型，可变参数和重载结合在一起，Josh
Bloch可能不会推荐的这种太宽泛的API。

让我与你分享10个微妙的Java编码最佳实践：

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

记得C++的析构函数？不记得了？那么你真的很幸运，因为你不必去调试那些由于对象删除后分配的内存没有被释放而导致内存泄露的代码。感谢Sun/Oracle实现的垃圾回收机制吧！

尽管如此，析构函数仍提供了一个有趣的特征。它理解逆分配顺序释放内存。记住在Java中也是这样的，当你操作类析构函数语法：

  • 使用JUnit的@Before和@After注释

  • 分配，释放JDBC资源

  • 调用super方法

还有其他各种用例。这里有一个具体的例子，说明如何实现一些事件侦听器的SPI：





1

2

3

4

5

6

7

8

9

10

11

@Override

public void beforeEvent(EventContext e) {

    super.beforeEvent(e);

    // Super code before my code

}

 

@Override

public void afterEvent(EventContext e) {

    // Super code after my code

    super.afterEvent(e);

}

臭名昭著的哲学家就餐问题是另一个说明它为什么重要的好例子。 关于哲学家用餐的问题，请查看链接：
http://adit.io/posts/2013-05-11-The-Dining-Philosophers-Problem-With-Ron-Swanson.html

规则：无论何时使用before/after,
allocate/free, take/return语义实现逻辑时，考虑是否逆序执行after/free/return操作。

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

向客户提供SPI可以使他们轻松的向你的库/代码中注入自定义行为的方法。当心你的SPI演进判断可能会迷惑你，使你认为你(不)打算需要附加参数。 当然，不应当过早增加功能。但一旦你发布了你的SPI，一旦你决定遵循语义版本控制，当你意识到在某种情况下你可能需要另外一个参数时，你会真的后悔在SPI中增加一个愚蠢的单参数的方法:





1

2

3

4

interface EventListener {

    // Bad

    void message(String message);

}

如果你也需要消息ID和消息源，怎么办？API演进将会阻止你向上面的类型添加参数。当然，有了Java8，你可以添加一个defender方法，“防御”你早期糟糕的设计决策：





1

2

3

4

5

6

7

8

9

10

11

12

interface EventListener {

    // Bad

    default
void message(String message) {

        message(message, null, null);

    }

    // Better?

    void message(

        String message,

        Integer id,

        MessageSource source

    );

}

注意，不幸的是，defender方法不能使用final修饰符。
但是比起使用许多方法污染你的SPI，使用上下文对象(或者参数对象)会好很多。





1

2

3

4

5

6

7

8

9

10

interface MessageContext {

    String message();

    Integer id();

    MessageSource source();

}

 

interface EventListener {

    // Awesome!

    void message(MessageContext context);

}

比起EventListner SPI你可以更容易演进MessageContext
API，因为很少用户会实现它。
规则:
无论何时指定SPI时，考虑使用上下文/参数对象，而不是写带有固定参数的方法。

备注:
通过专用的MessageResult类型交换结果也是一个好主意，该类型可以使用建设者API构造它。这样将大大增加SPI进化的灵活性。

3. 避免返回匿名，本地或者内部类

Swing程序员通常只要按几下快捷键即可生成成百上千的匿名类。在多数情况下，只要遵循接口、不违反SPI子类型的生命周期(SPI
subtype lifecycle)，这样做也无妨。
但是不要因为一个简单的原因——它们会保存对外部类的引用，就频繁的使用匿名、局部或者内部类。因为无论它们走到哪，外部类就得跟到哪。例如，在局部类的
域外操作不当的话，那么整个对象图就会发生微妙的变化从而可能引起内存泄露。

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

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





1

2

3

4

new HashMap<String, String>() {{

  put("1", "a");

  put("2", "b");

}}

这个方法利用了 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

2

3

4

5

6

listeners.add(new
EventListener() {

  @Override

  public void message(MessageContext c) {

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

  }

});

设想以JOOX的方式来处理XML。JOOX就包含很多的SAM：





1

2

3

4

5

6

7

$(document)

  // Find elements with an ID

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

  // Find their child elements

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

  // Print all matches

  .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。

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





1

2

3

4

5

6

7

8

9

10

11

File directory = // ...

 

if (directory.isDirectory()) {

  String[] list = directory.list();

 

  if
(list != null) {

    for
(String file : list) {

      // ...

    }

  }

}

大家觉得null检查有必要吗？大多数I/O操作会产生IOExceptions，但这个方法却只返回了null。Null是无法存放I/O错误信息的。因此这样的设计，有以下3方面的不足：

  • Null无助于发现错误

  • Null无法表明I/O错误是由File实例所对应的路径不正确引起的

  • 每个人都可能会忘记判断null情况

以集合的思维来看待问题的话，那么空的(empty)的数组或集合就是对“不存在”的最佳实现。返回空(null)数组或集合几乎是无任何实际意义的，除非用于延迟初始化。

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

7. 避免状态，使用函数

HTTP的好处是无状态。所有相关的状态在每次请求和响应中转移。这是REST命名的本质：含状态传输(Representational state
transfer)。在Java中这样做也很赞。当方法接收状态参数对象的时候从规则2的角度想想这件事。如果状态通过这种对象传输，而不是从外边操作状态，那么事情将会更简单。以JDBC为例。下述例子从一个存储的程序中读取一个光标。





1

2

3

4

5

6

7

8

9

10

11

12

CallableStatement s =

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

 

// Verbose manipulation of statement state:

s.registerOutParameter(1, cursor);

s.setString(2, "abc");

s.execute();

ResultSet rs = s.getObject(1);

 

// Verbose manipulation of result set state:

rs.next();

rs.next();

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

  • 在多线程环境很难正确的处理有状态的API

  • 很难让有状态的资源全局可用，因为状态没有被描述

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

8. 短路式 equals()

这是一个比较容易操作的方法。在比较复杂的对象系统中，你可以获得显著的性能提升，只要你在所有对象的equals()方法中首先进行相等判断:





1

2

3

4

5

@Override

public boolean equals(Object other) {

  if
(this == other) return
true;

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

}

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





1

2

3

4

5

6

@Override

public boolean equals(Object other) {

  if
(this == other) return
true;

  if
(other == null) return
false;

  // Rest of equality logic...

}

规则: 在你所有的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

2

void acceptAll(T... all);

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

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





1

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

编译器将T推断为<? extends Serializable &
Comparable<?>>，这将会使调用不明确！

所以无论何时你有一个“accept-all”签名（即使是泛型），你将永远不能类型安全地重载它。API使用者可能仅仅在走运的时候才会让编译器“偶然地”选择“正确的”方法。但是也可能使用accept-all方法或者无法调用任何方法。

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

结论

Java是一个野兽。不像其它更理想主义的语言，它慢慢地演进为今天的样子。这可能是一件好事，因为以Java的开发速度就已经有成百上千个警告，而且这些警告只能通过多年的经验去把握。

时间： 2024-10-20 00:43:13

10个精妙的Java编码最佳实践的相关文章

最重要的 Java EE 最佳实践

参考:IBM WebSphere 开发者技术期刊: 最重要的 Java EE 最佳实践 IBM WebSphere 开发者技术期刊: 最重要的 Java EE 最佳实践 2004 年 IBM? WebSphere? 开发者技术期刊中曾发表过一篇名称类似的文章,本文是其更新版本.这个修正版中考虑了一些不断变化的技术趋势,更重要的是推荐了一些作者认为应当广泛遵循.但尚未广泛遵循的实践. 2 评论: Keys Botzum, 高级技术人员 , EMC Kyle Brown, 杰出工程师, EMC Ru

Java自学最佳实践 &nbsp; get √

文/向右奔跑(简书作者)原文链接:http://www.jianshu.com/p/d99a1d7bb176 著作权归作者所有,转载请联系作者获得授权,并标注"简书作者". 大榜现在唯品会从事供应链金融开发,他初中毕业,没有读高中,大专读了一个成人类的电大.自学Java开发. 去年(15年)大榜在技术上像开了挂一样成长.2月份的时候,项目中要用到ActiveMQ,让他先了解,我上京东看了一下,只有一本原版书.他在公司内部进行技术分享完,跟我说,公司的牛人那么多,初中生也跟大家讲课了.5

python编码最佳实践之总结

一.数据结构的选择: 1. 在列表中查找: 对于已经排序的列表考虑用bisect模块来实现查找元素,该模块将使用二分查找实现 def find(seq, el) : pos = bisect(seq, el) if pos == 0 or ( pos == len(seq) and seq[-1] != el ) : return -1 return pos - 1 而快速插入一个元素可以用: bisect.insort(list, element) 这样就插入元素并且不需要再次调用 sort(

Java异常处理最佳实践及陷阱防范

前言 不管在我们的工作还是生活中,总会出现各种"错误",各种突发的"异常".无论我们做了多少准备,多少测试,这些异常总会在某个时间点出现,如果处理不当或是不及时,往往还会导致其他新的问题出现.所以我们要时刻注意这些陷阱以及需要一套"最佳实践"来建立起一个完善的异常处理机制. 正文 异常分类 首先,这里我画了一个异常分类的结构图. 在JDK中,Throwable是所有异常的父类,其下分为"Error"和"Excepti

编码最佳实践——单一职责原则

SOLID是一组最佳编码实践的首字母缩写 S 单一职责原则 O 开放与封闭原则 L Liskov(里式)替换原则 I 接口分离原则 D 依赖注入原则 同时应用这些最佳实践,可以提升代码适应变更的能力.但是凡事要有度,过度使用虽然可以让代码有很高的自适应能力,但是会导致层次粒度过小而难以理解或使用,还会影响代码的可读性. 单一职责原则 单一职责原则(Single Responsibility principle)要求开发人员编写的代码有且只有一个变更理由.如果一个类有多个变更理由,那么它就具有多个

Java 反射最佳实践 – 码农网

参考自 http://www.cnblogs.com/tianzhijiexian/p/3906774.htmlhttps://github.com/tianzhijiexian/HttpAnnotation/blob/master/lib/src/main/java/kale/net/http/util/HttpReqAdapter.java 原网页地址:http://www.codeceo.com/article/java-reflector.html... 概要:最简单优雅的使用反射. 本

Java Exception最佳实践（转）

https://www.dubby.cn/detail.html?id=9033 1.异常介绍 2.Java中的异常介绍 3.自定义异常 4.几个建议 1)不要生吞异常 2)申明具体的异常 3)尽可能的捕获具体异常 4)永远不要捕获Throwable 5)不要丢失异常信息 6)日志和上抛不可兼得 7)不要在finally里抛异常 8)不要为了捕获而捕获 9)不要使用printStackTrace()或类似的语句 10)不一定要catch 11)"Throw early catch late&qu

Atitit.嵌入式web 服务器 java android最佳实践

1. Android4.4.21 2. 自己的webserver1 3. CyberHTTP for Java  cybergarage6 1. Android4.4.2  First使用jetty9,三说jdk编译级别非常高的... i-jetty 就是jetty6的apk版本..马用.. 使用jetty6 ,三,jpg都ok....大的文件就jetty.io.EofException..找到资料没法儿解除...放弃..jetty6 的bug应该.. 子好自己实现web  server兰...

编码最佳实践——依赖注入原则

我们在这个系列的前四篇文章中分别介绍了SOLID原则中的前四个原则,今天来介绍最后一个原则--依赖注入原则.依赖注入(DI)是一个很简单的概念,实现起来也很简单.但是简单却掩盖不了它的重要性,如果没有依赖注入,前面的介绍的SOLID技术原则都不可能实际应用. 控制反转(IoC) 人们在谈论依赖注入的时候,经常也会谈到另一个概念--控制反转(IoC).按照大内老A的解释:"IoC主要体现了这样一种设计思想:通过将一组通用流程的控制权从应用转移到框架中以实现对流程的复用,并按照"好莱坞法则