选择使用哪一个解决方案，一部分取决于您的偏好，一部分取决于您的项目的性能和健壮性约束。

现在，让我们来研究一种乍一看好像完全错误的技术。

包含只抛出异常的方法

一开始，您可能会觉得这种做法天生就是错误的，而且有悖常理 ― 类应该仅包含实际对数据进行有意义操作的方法。特别是当您在给程序员教授面向对象编程时，包含诸如这样的类可能会令人大惑不解。

例如，考虑两种可能的定义 List 的类层次结构的方式，如以下的清单 4 和清单 5 所示：

清单 4. 不带通用 getter 的 List

abstract class List {} class Empty extends List {} class Cons extends List { 　 Object first; 　 List rest; 　 Cons(Object _first, List _rest) { 　　 first = _first; 　　 rest = _rest; 　 } 　 public Object getFirst() { 　　 return first; 　 } 　 public List getRest() { 　　 return rest; 　 } }

清单 5. 在接口中带有 getter 的 List

abstract class List { 　 public abstract Object getFirst(); 　 public abstract Object getRest(); } class Empty extends List { 　 public Object getFirst() { 　 throw new RuntimeException("Attempt to take first of an empty list"); 　 } 　 public List getRest() { 　 throw new RuntimeException("Attempt to take rest of an empty list"); 　 } } class Cons extends List { 　 Object first; 　 List rest; 　 Cons(Object _first, List _rest) { 　　 first = _first; 　　 rest = _rest; 　 } 　 public Object getFirst() { 　　 return first; 　 } 　 public List getRest() { 　　 return rest; 　 } }

诊断Java代码: 连续初始化器错误模式(6)

对于初学面向对象语言的程序员， List 的第一个版本（不带有通用 getter 的那个）背后的动机不会很令人费解。就直觉而言，除非一个方法做实际工作，否则类就不应该包含这个方法。不过以上关于处理缺省类的考虑事项也同样适用于这个示例。

不断地往代码插入强制转型，效率是很低的，而且会使代码变得拖泥带水。此外，类强制转型会给性能带来严重的后患，尤其是对于像 List 这样经常被调用的实用程序类。

就所有设计实践来说，当要考虑实践的深层动机时，这种做法是最适用的。这种动机并非总是适用的，所以，当它不适用时，就不应采用这种做法。

修正错误，情况会更好

您可能已经注意到（如果您阅读过我的论述错误模式的其它文章的话）连续初始化器错误有一点点不同。这一次我提供了不少如何解决这些错误的根本起因的想法，而不是仅仅将它修正。这是因为，在很多场合，我必须解决它们。那些可不是好差使。

而且，正如我们提到过的考虑事项所表明的，完全避免连续初始化要好得多。但当您必须处理它们时，至少能够保护您自己了。这里是这个错误模式的总结：

模式：连续初始化器。

症状：在未被初始化的域被访问的地方抛出了一个 NullPointerException 。

起因：有某个类，其构造函数并未直接初始化所有域。

处方及预防措施：在一个构造函数中初始化所有域。当没有更佳的值可使用时，使用代表缺省值的特殊类。对于有更佳的值可以使用的情况，包含多个构造函数。包含一个 isInitialized 方法。

在接下来的几个月里，我们将回到错误模式这个主题。下个月，我们将讨论一些 Java 语言中出现的与平台相关的错误。与普遍的看法相反，Java 语言并不是不受那类错误的影响。

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!