java - wsimport (xjc) - 为什么列表 getter 总是进行 null 检查？

Question

我想知道为什么(从 xsd)生成的列表 getter 总是进行 null 检查:

public class Response {

    @XmlElement(type = Integer.class)
    protected List<Integer> integers;

    public List<Integer> getIntegers() {
        if (integers == null) {
            integers = new ArrayList<Integer>();
        }
        return this.integers;
    }
}

问题:

为什么？是什么原因？有什么好的吗？

我这么问是因为在某些情况下这不是一件好事。看起来没有办法改变这种行为。

Answer 1

经过一番挖掘，原因就很清楚了。我使用 xjc 生成了一些代码，对于列表属性，它创建了以下注释:

/**
 * Gets the value of the bars property.
 * 
 * <p>
 * This accessor method returns a reference to the live list,
 * not a snapshot. Therefore any modification you make to the
 * returned list will be present inside the JAXB object.
 * This is why there is not a <CODE>set</CODE> method for the bars property.
 * 
 * <p>
 * For example, to add a new item, do as follows:
 * <pre>
 *    getBars().add(newItem);
 * </pre>
 * 
 * 
 * <p>
 * Objects of the following type(s) are allowed in the list
 * {@link Bar }
 * 
 * 
 */

这表明了他们的意图。他们希望对象不可能有陈旧的 List，因此它总是返回 Activity 列表而不是制作副本。这意味着对 getter 的多次调用(例如，从不同的线程或不同的上下文)将始终获得对同一内存中对象的引用。然而，这样做意味着他们不能有 setter，或者他们会违反这个契约——上下文 A 可以设置该值，然后上下文 B 就会有一个对旧值的陈旧引用，并且没有办法知道它已被更改。

由于该设计决策，他们无法拥有 setter ，因此如果您需要添加或删除项目，则需要某种方法来改变列表。否则，最初的 null 列表将永远为 null(除非有反射的恶作剧)。因此，唯一剩下的方法是在 getter 中检查 null，并在那时进行惰性初始化。这意味着替换整个列表的方案必须是

foo.getBars().clear();
foo.getBars().addAll(someList);

至于他们为什么选择这种设计......团队之外的任何人都无法知道答案。然而，对于大多数代码来说，这通常是一个非常好的模式(它减少了耦合，并消除了编译器无法警告您的常见错误情况)，因此很难对它提出很多反对意见。如果它确实给你带来了麻烦(并且你还没有真正展示它是怎么回事，除了你的一些对象在复制操作后有空列表而不是空列表这一事实之外)，那么我能给你的唯一建议是要么不使用代码生成器，要么为 xjc 编写扩展以使其执行您想要的操作。甚至可能有一个现有的扩展。我不知道。