Re: dispatch class, modularity, initialisation?
bugbear wrote:
I would like to have a base class
"Widget", that amongst other things
has a method getWidgetFor(String name).
I would like this method to be able to use (e.g.)
a Widget class static HashMap to look up Widgets.
Each entry in the Map will be an instance
of a sub-class of widget; some sub-classes
may "want" to put more than one entry in the map.
By this, do you mean that a subclass may want to add more than one key, each
with its own value?
So - how do I populate the map?
Have each class register itself with the parent class's registry as part of
its static initializer.
public class Sub extends Widget
{
static
{
synchronized ( Widget.registry )
{
registry.put( aKey, someValue );
registry.put( bKey, otherValue );
...
}
}
}
Obviously all get()s from the registry must be synchronized on the registry, too.
If I have a static block in each sub-class,
I have no trivial way of ensuring
that ALL my subclasses have been referred
to (thus loading them, and running any static
code blocks).
Nope. Just the ones that have initialized.
One cannot, in general, determine all subclasses from the parent class,
because new subclasses can be loaded at any moment, including /just/ after
taking inventory.
OTOH, each subclass knows of its own existence as it's born, thus can register
itself as part of its initialization. Thus, while you cannot determine /a
priori/ that each subclass has been registered, each subclass can guarantee
that it will not be used until it's registered.
If I have an "init()" method in each sub-class,
it might be called more than once.
Not if you code it right, make it no more visible than package-private, and
use a factory method instead of a constructor.
SadRed wrote:
As the value of the Map, use Collection<Entry> instead of a bare Entry
object.
bugbear wrote:
I don't understand what part of my problem this helps;
please expand?
It's a bad idea to keep a collection of Map.Entry as a value, if that's what
was meant by the advice. It might be a good idea to keep a Collection<V> or
Collection<? extends V> where V is the type of your values.
I think SadRed is solving your problem of subclasses registering more than one
entry, on the reading that you wanted to keep more than one value per key, but
I'm not sure that's what was meant. I do know that I had to read the original
post to see if that's what you wanted, or if you wanted to keep several values
per subclass that have different keys.
One also wonders how you prevent key collisions between subclasses. Perhaps
you need a key that is a Pair< Class<? extends Widget>, ? extends KeyType > as
the key to your map. Thus each subclass entry is keyed by its own class and
its own key values,
--
Lew