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? | [reply] |
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.
| [reply] |
Why not have the Factory maintain the registry and keep the two separate? The programmer who comes after you will bless you continuously. (If you don't, expect curses.)
------
We are the carpenters and bricklayers of the Information Age. Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement. | [reply] |
This is what you were referring to earlier by Manifest, correct?
Matt
| [reply] |