Re: passing a Factory to a method to create a generic instance
On Sat, 10 May 2008, Lew wrote:
Tom Anderson wrote:
On Sat, 10 May 2008, thufir wrote:
On Sat, 10 May 2008 01:19:13 +0100, Tom Anderson wrote:
Before i go on, i should say that in the classical application of the
Factory pattern, yes, you would make something more specific than an
Object, because the different factories would be making different
versions of something, or the same thing in different ways. Like you
might define a WidgetFactory, then have concrete factories that make
Nut, Bolt, Screw, etc objects, all of which are subtypes of Widget.
Does there have to be a Nut factory, or can I just use the Widget factory?
I'm not seeing the advantage of WidgetFactory, because I don't seem able
to use it.
WidgetFactory is abstract. NutFactory etc are concrete implementations of
it. Sorry if i haven't explained this clearly.
abstract class Widget {
}
class Nut extends Widget {
}
class Bolt extends Widget {
}
abstract class WidgetFactory {
abstract Widget make() ;
}
class NutFactory extends WidgetFactory {
Widget make() {
return new Nut() ;
}
}
class BoltFactory extends WidgetFactory {
Widget make() {
return new Bolt() ;
}
}
// a usage example
class CratePacker
{
Crate pack(int number, WidgetFactory fac) {
Crate c = new Crate() ;
for (int i = 0 ; i < number ; ++i)
c.add(fac.make()) ;
return c ;
}
}
The point is to be able to pack crates of widgets with one method, which
can be parameterised with a factory which defines the kind of widget.
Closures? We don't need no steenkin' closures!
Heh! An option i didn't mention was to use an anonymous class for the
factory:
Crate boxOBolts = CratePacker.pack(200, new WidgetFactory() {
Widget make() {return new Bolt() ;}
}) ;
Which is basically a closure in a fancy costume, and would mean you didn't
need the concrete factory classes.
With first-class functions, you could even make the CratePacker take a
FUNCTION FROM void TO Widget or whatever it'd be called, and then pass in
a Widget class's constructor. That's what i do in python.
In this simple example, Wdiget should be an interface rather than a
class, but that in no wise detracts from the main point of the example.
Widget or WidgetFactory? In this example (or rather, the hypothetical
expanded real-world case it's a cartoon of), whether Widget is an
interface or a class depends on design considerations related to what
Widgets do, rather than the use of the factory pattern - do they have code
they can share? Even if not, if the main thing that a Bolt is is a kind of
Widget, i'd say use an abstract base class, not an interface, since it
communicates a stronger sense of is-a. WidgetFactory, though, yes, that
could well be an interface.
tom
--
I DO IT WRONG!!!