java - 空对象还是虚拟对象？

Question

考虑一个批处理操作，它可能需要很长时间才能完成它的工作(取决于数据)。 用户可以注册一个OPTIONAL 监听器来跟踪作业进度。

NOTE: listener registration is totally optional and user may want to call the job without registering any listener.

问:您更喜欢以下哪些解决方案，为什么？

EDIT: the concern here is performance vs clean code. some say, checking null reference (solution 1) is faster compare to second solution. but second solution is cleaner and more understandable. I would like to have your opinion.

No 1: 允许 null listener 并始终检查 listener 是否不为 null，然后调用它。

doMyBatchJob() {
   if (listener != null) {
      listenr.progressStarted(params);
   }
   while (x) {
      if (listener != null) {
          listener.progressUpdated(current, expected)
      }
   }
   if (listener != null) {
      listenr.progressFinished(params);
   }
}

否 2:实现一个虚拟监听器，如果用户没有传递他/她自己的监听器，则注册它。 这样就可以在不检查空对象的情况下调用监听器。

DummyListener {
     public void progressStarted(params) { //DO NOTHING }
     public void progressUpdated(current, expected) { //DO NOTHING }
     public void progressFinished(params) { //DO NOTHING }
}

doMyBatchJob() {
   listener.progressStarted(params);
   while (x) {
         //Do a single unit of the batch operation
         // ... code omitted here
         listener.progressUpdated(current, expected)
   }
   listener.progressFinished(params)
}

Answer 1

您对 if x==null 是一种代码味道的担忧是正确的，它绝对是!

使用 Null Object 有非常正当的理由模式，一个是避免在您的代码中乱扔 if (x == null) 噪声，这些噪声通常与业务相关性较低，而与设计相关性较差。 NULL 表示缺少值不是默认值。

我认为您对 Null Object 模式的了解还不够。

永远不会返回 null，也永远不必检查它

首先永远不要从方法中return null 并且永远不要在代码中使用if x == null。两者都是设计不佳的明显迹象。 null 引用和 NPE 应该是一个错误，应该在没有发生的地方解决。

永远不要接受 null，也永远不必检查它。

具有返回 null 的方法返回一个 Null 对象 并且具有接受 null 并可能处理 null 的事物 引用具有 Null 对象 用于处理 Null References 的实现。

在您的情况下，您的 Dummy 对象不会只是什么都不做，它应该向日志警告报告它遇到了 null 并且应该对此做些什么。

使用一个好的 JSR305 库来注释您的方法，这样它们就不会接受空值。

我有 com.google.code.findbugs我创建的每个 Java 程序中的 maven 依赖项，无论多么微不足道，然后我都可以用 @NONNULL 修饰每个方法和方法参数，而不必担心编写 if x == null 再一次!

如果您有返回 null 的第 3 方代码，请包装它并使用 JSR305 注释。

将 Guava Preconditions.checkNotNull() 与 static 导入一起使用，这样您就可以对标记为 @Nonnnull，您甚至可以包含一条描述性错误消息，说明什么是 null 以及为什么它不应该是什么。

然后自鸣得意地想想他们的代码设计得多么糟糕。