[squeak-dev] Re: A question on the builder pattern

Andreas Raab andreas.raab at gmx.de
Tue May 4 05:55:11 UTC 2010


On 5/3/2010 10:31 PM, Colin Putney wrote:
>
> On 2010-05-03, at 8:05 PM, Andreas Raab wrote:
>
>> What I'm curious about is this: Which advantage does "form b" have over "form a"? Why would one choose it? Is it merely for convenience or are there other (practical or style) advantages?
>
> Here's one thing that comes to mind:
>
> Form b doesn't use an intermediate representation in the form of spec classes. OmniBrowser uses this form: the model objects implement #buildOn:, which sends messages to a builder object. The builders never answer anything interesting to the model objects, they just take direction on how to build up the widget hierarchy. That keeps the whole thing quite light-weight - one builder class for each GUI library supported (Morphic, web and test), and everything is done in a single pass.

Thanks for the pointer, I need to look at this.

> Now, OB is pretty simple compared to say, ToolBuilder - it only uses a narrow range of widgets, and they don't require very many parameters. And for some situations an intermediate representation might be useful; you can do transformations on it before producing the final output. But when that's *not* the case, I favour the simplicity of form b.

That's what I was wondering about. I'm really not certain what the 
tradeoffs are for each form. For example, I'm not certain that the 
number of attributes in ToolBuilder is *that* large; most of the 
properties are fairly polymorphic amongst the widget types. Abstracting 
some of this stuff away could be useful and like you're pointing out 
this may be even simpler to use.

> BTW, any discussion of builder protocols would be incomplete without mentioning Seaside. It has a pretty powerful builder interface for programmatically generating HTML. It's hybrid of forms b and c, with nested builders *and* scoped blocks. It's also the second version of the interface; the first version used a single builder with nested blocks.

Yeah, the only reason why I've left it out is that I'm not very familiar 
with Seaside and although I've seen the HTML interface I wasn't sure how 
applicable it would be in the context of this discussion since I don't 
know whether the HTML interface actual creates some sort of HTML object 
tree or if it's simply used as a (stream) output device.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list