Re: dispatch class, modularity, initialisation?
bugbear wrote:
I'm starting to think that the base class is the correct
place for this knowledge, and that a static block
in the base class would be a perfectly "clean" place
to populate the registry by simple performing code along
the lines of:
registry.add("nigel", new WidgetA());
registry.add("george", new WidgetB("arbitrary"));
registry.add("henry", new WidgetB("something"));
Indeed. If you take that one step more, you will externalize the sub-class
names to a properties file and let them all have just the default constructor.
Let each subclass handle its own "arbitrary" or "something" in its own
initialization (instance preferred to static). Use Class.newInstance() off
the class object stored as the value, which class object was reflectively
created upon base class static initialization or static init() method (or even
reInit()) based on the externalized properties.
E.g., (untried, uncompiled)
public class Base
{
private static final Map registry = new HashMap();
// or could use Collections.synchronizedMap()
private static void initRegistry()
{
Properties props = getProperties();
Map mappings = new HashMap();
for ( Iterator iter = props.keySet().iterator(); iter.hasNext(); )
{
String key = (String) iter.next();
// here you might have logic to decide whether to use this key
String name = props.getProperty( key );
Class clazz = Class.forName( name ); // try...catch omitted for clarity
mappings.put( key, clazz );
}
synchronized ( registry )
{
registry.putAll( mappings );
}
} // end initRegistry()
private static Properties getProperties()
{
Properties p;
// read the properties from a resource
return p;
}
}
--
Lew