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!!!
.

Relevant Pages

  • Re: passing a Factory to a method to create a generic instance
    ... Nut, Bolt, Screw, etc objects, all of which are subtypes of Widget. ... class Bolt extends Widget { ... 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. ...
    (comp.lang.java.programmer)
  • Re: Software design patterns: encapsulation & object identity
    ... > constructs, maintains, and issues GOF Singleton instances of a Widget. ... > Clients of the Factory instance obtain the Widget Singleton instance ... > APIs) the fact that the instances issued to clients are Singletons? ...
    (comp.object)
  • Re: passing a Factory to a method to create a generic instance
    ... Does there have to be a Nut factory, or can I just use the Widget factory? ... class Bolt extends Widget { ... Crate pack{ ...
    (comp.lang.java.programmer)
  • Re: BVT, a just tax [1]
    ... >factory somewhere, thus creating a lot of jobs, the company knows it will ... shareholders and creditors, to employ. ... of widget the company builds more profitably and expanding the market ... The development of company towns was driven by far more than an attempt ...
    (sci.econ)