Re: Builders/Factories and Inheritance.
Tom Anderson wrote:
On Sat, 16 Aug 2008, Daniel Pitts wrote:
I was just thinking about the Builder pattern (because of Roedy's
recent post).
Stop - digression time! I get the impression that there are at least two
different patterns that go by the name 'Builder'.
I don't own a copy of the Gang of Four book, so i can't check what they
wrote, but i think they describe something that's a bit like the
relationship between an XML parser and a DocumentFactory, where you have
a Director that knows what steps have to be performed, and a Builder
that knows how to execute the steps, and where the steps ultimately
yield a complex Product of some sort. To put it another way, the Builder
provides the primitives, and the Director uses the primitives. This
allows decoupling of organisation and the details of the representation
- in the XML case, the factory can build DOM nodes optimised for size,
or for speed, or with javascript support, or using some persistence
technique to transparently handle huge documents, or whatever.
The other pattern, which i *think* might originate in a talk by Josh
Bloch, is where a Builder is essentially a mutable, fairly passive
holder for state that is then used to construct some Product in a single
big-bang constructor invocation. The point of this is that you can make
creation of the Product easier without having to allow
partially-constructed Products to exist.
I think they are possibly similar enough in concept that they can be
called the same thing. The big difference between a configurable
factory, and a Builder in the sense that you presented is that the order
of method invocation doesn't typically matter on the "Factory" (save the
factory method), where it does on the builder. Take StringBuilder as a
very basic example. Its output depends on the order that methods are
called on the builder object, where as a Factory class usually shouldn't
care the order that a property is configured, as long as enough are
configured at factory time.
It seems to me that Builders are a special type of Factory, and in
general Factories /tend/ to prevent the client from specifying the
actual implementation to use. I was thinking about ways to give the
client some control, while allowing the builder to do its job as-well.
I was thinking of a double-indirection factory (bad name maybe?)
What you've got here is a combination of Builder and Decorator. Sort of.
This seems like it *might* be an anti-pattern, but I'm not sure. Have
any of you had to implement this design? How did it work out? I don't
actually have any real code for this, since I'm just thinking "out
loud" at the moment.
I've never written a class complicated enough to need this sophisticated
a construction pattern, but imagine if i did, it would be a good solution.
The major alternative is to subclass FooBuilder to make
SpecialFooBuilder, adding the extra fields and setters, and then
overriding the build() method. That would, i think, be simpler, but i
think your approach is cleaner. Also, it's compatible with the use of
the first style of Builder above, in that the kind of FooBuilder can be
varied, while using the same SpecialFooBuilder. Although in your case,
the FooBuilder is really a Director. I think.
Interesting, I'll have to think about that some more. It could be that
SpecialFooBuilder is actually a Strategy, rather than a Factory; that
might would make FooBuilder a Director.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>