in reply to Re: Re: Constructor/Factory Orthodoxy
in thread Constructor/Factory Orthodoxy

Hmmm. I can see the technique but frankly I'd have to see some good uses of it before being convinced. Have you put this concept to use (or at least seen it done well)?

Given your technique I'd be just as inclined to say you could do the same with a factory class and keep the two apart.

What is your opinion of the two?
  • Comment on Re: Re: Re: Constructor/Factory Orthodoxy

Replies are listed 'Best First'.
Re: Re: Re: Re: Constructor/Factory Orthodoxy
by dws (Chancellor) on Feb 26, 2003 at 01:43 UTC
    I can see the technique but frankly I'd have to see some good uses of it before being convinced. Have you put this concept to use (or at least seen it done well)?

    I first saw this technique used to handle multiple "look and feels" when drawing widgets. You would ask the factory for a new scrollbar, it would consult a policy object, which would tell it what (available) class to use, and the factory would hand back a new instance of whatever type the policy object said to use.

    I've also used a similar technique when building "plugin" mechanisms. At startup, the application reads and initializes a set of plugins, each of which inherits from Plugin. At initialization time, each plugin registers itself with Plugin. Plugin provides factory methods, a query method that hands back the names of all registered plugins, and a mapping of plugin name to plugin instance.