Re: Builders/Factories and Inheritance.
Daniel Pitts wrote:
class FooBuilder {
private final FooFactory factory;
public FooBuilder(FooFactory factory) {this.factory = factory;}
public FooBuilder() {this.factory = new DefaultFooFactory();}
// builder methods etc...
public Foo toFoo() { return factory.createFoo(getBar(), getBaz()); }
}
This bit here seems very similar to "The Service Provider Pattern." You
might want to check that out. The FooFactory you have seems to be
providing the the "service" of building Foos.
This would work a bit like JDBC, where the end-user specifies some
action to connect, and the framework is able to find the particular
connector ("client" in you example), install it as the factory builder,
and return a requested instance. All in one go...
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 don't think it's an anti-pattern, but it might be a sophisticated one
that isn't used all the time due to it's internal complexity. Like
JDBC. You'd have to know a lot about how the FooBuilder super class
worked to be certain you implemented all the needed requirements. If
the requirements are trivial, then I don' think the builder pattern is
as useful. The more complex the builder, the more useful it is.
I'd probably make FooBuilder into an interface (assuming the builder is
complex enough to be practical, it probably warrants an interface).