Re: Builders/Factories and Inheritance.
Ed Kirwan wrote:
Daniel Pitts wrote:
I was just thinking about the Builder pattern (because of Roedy's recent
post).
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.
(Nose-diving towards OT): I appreciate the highlighted, "Tend," though I
find that 90% of my client interaction with factories is via the
parameterised factory method (in which, as you know, the client has rather
a sizable say in the returned object though without ever dirtying itself
with knowledge of the actual implementation) rather than naked factories
themselves.
Where I use factories proper, they tend to decide the returned object based
on environmentally-specified configuration options.
Just my two kroner.
Granted, that is the most common use-case for builders/factories. It
does allow the client to "not care" about the actual implementation
type. This is good in most cases, but there are times when the client
might want to alter some behavior, and writing a delegate or wrapper
instead of overriding a method or two doesn't make sense or isn't
feasible. Of course, that problem can probably be solved in other ways
(Decorator pattern, for instance.)
Thanks for the feed back.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>