What is the best practice for using Builder pattern in "deep" object hierarchies? To elaborate, I explored the idea of applying the Builder pattern as proposed by Joshua Bloch, to my XML binding code (I am using SimpleXML but this question would apply to any case). My object hierarchy is 4 levels deep, with various degree of complexity. By that, I mean, in some levels I have just a couple of properties for my objects, whereas at some other levels I have up to 10.
So consider this hypothetical example (I am leaving out the Simple XML annotations for brevity)
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 ..*/
}
If I wanted to enforce creation of the Outermost object using builders, what would be the best way to go about it? The most obvious answer is to have inner static Builder classes for each of the above classes.
But, wouldn't that make things as unwieldy as the very problem Builder pattern tries to solve? I am thinking about stuff like - this will enforce an "inside out" approach - meaning that the Innermost object will have to be fully constructed and instantiated before it can be added to the Middle object. But we all know that in practice (especially when one is building XML or JSON), we rarely have "timely" information to accomplish this.
Chances are, one will end up having variables for each and every property - across all levels; and create the objects in the very end. OR, one will end up having Builder for multiple levels floating around in the code, adding to the confusion.
So, any ideas on how to elegantly accomplish this?
The description of the Builder Pattern here is I guess what you are referring to; it's a .little different than the pattern described in Wikipedia here, I prefer the former.
I don't see that your concerns about order of construction or loss of encapsulation inevitable follow from the descriptions I read. For me the big question is the structure of your raw data.
Suppose we have
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);
}
}
Now we can create as many middleBuilders as we need
while (middleDataIter.hasNext() ) {
MiddleData data = middleDateIter.next();
// make a middle builder, add it.
}
We can apply the same pattern to the further levels of nesting.
To address your first point, a variable for every property: depends on how we design the builders and where our data is coming from. If we're, say coming from a UI then we pretty much have a variable per property anyway, we're no worse off. If as per my suggestion above we're iterating some data structure, then maybe the builder takes responsibility for iterpreting that data structure. In my example we pass MiddleData instances down. Some extra coupling but it does encapsulate the details.
To address your second point we don't build things as we go, instead we're effectively using the builder as the accumulation point for the data. Eventually we call the "Go and Build" method, but at that point we should have all the data in place so the whole hierarchy just builds.