Java Builder 模式和“深”对象层次结构

在“深层”对象层次结构中使用生成器模式的最佳实践是什么？为了详细说明，我探索了将 Joshua Bloch 提出的 Builder 模式应用到我的 XML 绑定代码的想法（我使用的是 SimpleXML，但这个问题适用于任何情况）。我的对象层次结构有 4 层深，具有不同程度的复杂性。我的意思是，在某些关卡中，我的对象只有几个属性，而在其他一些关卡中，我的对象最多有 10 个属性。

因此，请考虑这个假设的示例（为了简洁起见，我省略了简单 XML 注释）

public class Outermost {

    private String title;
    private int channel;
    private List<Middle> middleList;

}

class Middle{
    private int id;
    private String name;
    private boolean senior;
    /* ... ... 10 such properties */

    private Innermost inner;
}

class Innermost{
    private String something;
    private int foo;
    /* ... Few more of these ..*/
}

如果我想强制创建Outermost使用构建器的对象，最好的方法是什么？最明显的答案是inner static Builder上述每个类别的类别。

但是，这不会让事情变得像构建器模式试图解决的问题一样难以处理吗？我正在考虑类似的事情 - 这将强制实施“由内而外”的方法 - 意味着Innermost对象必须先完全构造并实例化，然后才能添加到Middle目的。但我们都知道，在实践中（尤其是在构建 XML 或 JSON 时），我们很少有“及时”信息来完成这一任务。

很有可能，我们最终会为所有级别的每个属性都设置变量；并在最后创建对象。或者，最终会在代码中出现多个级别的 Builder，从而增加混乱。

那么，关于如何优雅地实现这一点有什么想法吗？

建造者模式的描述here http://rwhansen.blogspot.com/2007/07/theres-builder-pattern-that-joshua.html我猜你指的是什么；它与维基百科中描述的模式有点不同here http://en.wikipedia.org/wiki/Builder_pattern，我更喜欢前者。

从我读到的描述中，我不认为您对构造顺序或封装损失不可避免的担忧。对我来说，最大的问题是原始数据的结构。

假设我们有

 public OuterBuilder {
     // some outer attributes here

     private ArrayList<MiddleBuilder> m_middleList;

     public OuterBuild( mandatory params for Outers ){
          // populate some outer attributes
          // create empty middle array
     }

     public addMiddle(MiddleBuilder middler) {
              m_middleList.add(middler);
     } 
 }

现在我们可以根据需要创建任意数量的 middleBuilder

 while (middleDataIter.hasNext() ) {
      MiddleData data = middleDateIter.next();
      // make a middle builder, add it.
 }

我们可以将相同的模式应用于更高级别的嵌套。

为了解决你的第一点，每个属性都有一个变量：取决于我们如何设计构建器以及我们的数据来自哪里。如果我们来自 UI，那么我们几乎每个属性都有一个变量，我们的情况也不会更糟。如果按照我上面的建议，我们正在迭代某些数据结构，那么构建器可能负责解释该数据结构。在我的示例中，我们向下传递 MiddleData 实例。一些额外的耦合，但它确实封装了细节。

为了解决你的第二点，我们不会边走边构建东西，而是有效地使用构建器作为数据的积累点。最终我们调用“Go and Build”方法，但此时我们应该拥有所有数据，以便构建整个层次结构。