Re: Interface with implied Constructor
On 15.07.2013 17:58, Kevin McMurtrie wrote:
In article <b4fvsjF33d6U1@mid.individual.net>,
Robert Klemme <shortcutter@googlemail.com> wrote:
On 12.07.2013 04:11, Kevin McMurtrie wrote:
There's a builder pattern than works. It's a little ugly but it's what
you have when you can't use abstract classes for some reason. Move
around the interfaces as you see fit.
<snip/>
I'd call that "factory pattern". Why did you pick "builder"?
They're similar. I've seen the term "builder" used more often when the
construction is done by the implementor and "factory" more often when
the construction is performed by a single system. Builder also has a
pattern of SomeThing a= new
Builder().with(Options.B).add(x).add(y).addAll(Z).makeImmutable(); It's
a way to specify arguments after construction without allowing access to
a partially built object.
But you do not use that feature of chaining in your sample code. To me
that's a plain factory. If you had taken advantage of Builder you would
have had an interface like this, I believe:
interface MyThing {
...
}
public interface MyThingBuilder {
MyThingBuilder addArg1(int arg1);
MyThingBuilder addArg2(int arg1);
MyThing finish();
}
The consistency checking ("Do we have all the arguments?") is put into
the MyThingBuilder implementation and the client can rely on the
returned MyThing to be complete so not all methods of MyThing have to
check state (a concern that has been voiced).
It's a bit like Command pattern applied to object construction: the
command object's configuration methods (addArg1 and addArg2 above)
replace constructor arguments and the construction is eventually done by
a no argument method.
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/