我在这里对构建器模式的描述是您所指的;它与Wikipedia
此处描述的模式略有不同。我更喜欢前者。
我没有看到您对构造顺序或封装丢失的担心不可避免地遵循了我所阅读的描述。对我来说,最大的问题是原始数据的结构。
假设我们有
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”方法,但是到那时我们应该将所有数据都放在适当的位置,这样才可以构建整个层次结构。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)