我是否应该始终初始化 Java 中的实例变量？

Question

我最近开始了一个新项目，我试图让我的实例变量始终初始化为某个值，因此它们在任何时候都不为空。下面的小例子：

public class ItemManager {

  ItemMaster itemMaster;
  List<ItemComponentManager> components;

  ItemManager() {
    itemMaster = new ItemMaster();
    components = new ArrayList<ItemComponentManager>();
  }

  ...
}

重点主要是避免在代码中某处使用实例变量之前对 null 进行繁琐的检查。到目前为止，它运行良好，并且您大多不需要 null-值，因为您还可以检查空字符串或空列表等。我没有将这种方法用于方法范围的变量它们的范围非常有限，因此不会影响代码的其他部分。

这一切都是实验性的，所以我想知道这种方法是否可行，或者是否有一些我还没有看到的陷阱。保持初始化实例变量通常是个好主意吗？

Answer 1

我通常将空集合和空集合视为两个独立的东西：

空集合意味着我知道可用的项目为零。 null 集合会告诉我我不知道集合的状态，这是另一回事。

所以我真的不认为这是非此即彼的。如果我在构造函数中初始化它们，我会声明变量 final 。如果您将其声明为 final，那么读者将非常清楚此集合不能为空。

Answer 2

首先，如果您想保留控制权，所有非最终实例变量必须声明为私有！

也考虑惰性实例化——这也避免了“坏状态”，但只在使用时初始化：

class Foo {
    private List<X> stuff;
    public void add(X x) {
        if (stuff == null)
            stuff = new ArrayList<X>();
        stuff.add(x);
    }
    public List<X> getStuff() {
        if (stuff == null)
            return Collections.emptyList();
        return Collections.unmodifiableList(stuff);
    }
}

（注意 Collections.unmodifiableList 的使用——除非你真的希望调用者能够从你的列表中添加/删除，你应该让它不可变）

考虑将创建多少个相关对象的实例。如果有很多，并且您总是创建列表（并且最终可能会得到许多空列表），那么您可能会创建比您需要的更多的对象。

除此之外，这真的是一个品味问题，以及你在构建时是否可以拥有有意义的价值。

如果您正在使用 DI/IOC，您希望框架为您完成工作（尽管您可以通过构造函数注入来完成；我更喜欢 setter） -- 斯科特

Answer 3

我会说这完全没问题 - 只要您记得那里有“空”占位符值而不是真实数据。

将它们保持为 null 的好处是迫使您处理它们 - 否则程序会崩溃。如果您创建了空对象，但忘记了它们，您会得到未定义的结果。

并且只是对防御性编码进行评论 - 如果您是创建对象的人并且从不将它们设置为 null，则无需每次都检查 null。如果由于某种原因你得到空值，那么你就知道发生了灾难性的错误，程序无论如何都会崩溃。

Answer 4

如果可能的话，我会让它们final。然后它们必须在构造函数中初始化，并且不能为空。

在任何情况下，您还应该将它们设为私有，以防止其他类将 null 分配给它们。如果您可以检查您的班级中从未分配过 null，那么该方法将起作用。

Answer 5

我遇到过一些导致问题的案例。 在反序列化期间，一些框架不会调用构造函数，我不知道他们如何或为什么选择这样做，但它确实发生了。这可能导致您的值为null。我也遇到过调用构造函数但由于某种原因没有初始化成员变量的情况。

实际上，我会使用以下代码而不是您的代码：

public class ItemManager {

  ItemMaster itemMaster = new ItemMaster();
  List<ItemComponentManager> components = new ArrayList<ItemComponentManager>();

  ItemManager() {
     ...
  }
  ...
}

Answer 6

我处理我声明的任何变量的方式是决定它是否会在对象（或类，如果它是静态的）的生命周期内发生变化。如果答案是“否”，那么我将其定为最终结果。

使它最终强制你在创建对象时给它一个值......我个人会做以下事情，除非我知道我会改变重点：

私人最终ItemMaster itemMaster； 私有最终列表组件； // 实例初始化块 - 发生在构造时 { itemMaster = new ItemMaster(); 组件 = 新的 ArrayList(); }

您的代码现在的方式是您必须始终检查 null，因为您没有将变量标记为私有（这意味着同一包中的任何类都可以将值更改为 null）。

Answer 7

是的，在构造函数中初始化所有类变量是个好主意。

Answer 8

重点主要是避免 使用前繁琐的 null 检查 某处的类变量 代码。

您仍然需要检查是否为空。第三方库甚至 Java API 有时会返回 null。

另外，实例化一个可能永远不会使用的对象是一种浪费，但这取决于你的类的设计。

Answer 9

对象在构建后应该 100% 准备就绪。用户不必检查空值。防御性编程是要走的路——保持检查。

为了 DRY，您可以将检查放在 setter 中，然后让构造函数调用它们。这样您就不会对检查进行两次编码。

Answer 10

如果这是您的所有代码并且您想设置该约定，那么拥有它应该是一件好事。不过，我同意 Paul 的评论，没有什么可以阻止某些错误代码意外地将您的类变量之一设置为 null。作为一般规则，我总是检查空值。是的，这是一个 PITA，但防御性编码可能是一件好事。

Answer 11

从“ItemManager”类的名称来看，ItemManager 在某些应用程序中听起来像是一个单例。如果是这样，您应该进行调查，并且真的，真的，知道依赖注入。使用 Spring (http://www.springsource.org/) 之类的东西来创建 ItemComponentManagers 列表并将其注入 ItemManager。

如果没有 DI，在严肃的应用程序中手动初始化是一场噩梦，要调试并连接各种“管理器”类来进行狭窄的测试是地狱。

始终使用 DI（即使在构建测试时）。对于数据对象，创建一个 get() 方法，如果列表不存在则创建该列表。但是，如果对象很复杂，几乎可以肯定的是，使用 Factory 或 Builder 模式会让您的生活变得更好，并让 F/B 根据需要设置成员变量。

Answer 12

如果在您设置的一种方法中会发生什么

itemMaster = null; 

或者您将 ItemManager 的引用返回给某个其他类，并将 itemMaster 设置为 null。 （您可以防止这很容易返回您的 ItemManager 等的克隆）

我会尽可能保留支票。