Abstraction problem

Question

I'm trying to develop a CommandFactory that can, given a known set of parameters, instantiate one Command in a dynamic set of Commands.
class CommandFactory
  Hashtable commandKeys;
  private static CommandFactory instance = null;
  private CommandFactory()
    //code that initializes and populates commandKeys
  public static CommandFactory getInstance()
    if( instance == null ) instance = new CommandFactory();
  public Command parse( String cmd )
    String key = cmd.substring(0,cmd.indexOf(" "));
    String cmd_parms = cmd.substring( cmd.indexOf(" ")+1 );
    Method m = (Method)commandKeys.get(key);
    return (Command) m.invoke( null, new Object[] { cmd_parms } );
public abstract class Command
  public abstract execute();
}Now, I'd like to be able to know at compile time that every sub-class of Command has a static method defined such as:
//adding to my above Command a bit
abstract class Command
  public abstract void execute();
  public abstract static Command parse( String cmd );
class CommandSubclass
  public void execute()
    //do something
  public static Command parse( String cmd )
    //does something
   return newCommand;
}The closest thing I can think of to naming what I want here is an abstract static method. That way at compile-time I know with certainty that the Command subclasses have the proper tidbits to initialize and give me back a Command.
Now, I know that Java does not support abstract static methods. And what I've done instead is just assume that my various Command classes have the "parse" static method. But I run the risk of not knowing until run-time that a Command subclass does not have the needed static method.
Essentially, I need a means to enforce a uniform way of initializing subclasses of an abstract superclass. Anyone know how to get that other than reflection, hoping, and praying? Or, is there a different pattern I should be using here?
Thanks,
--mb

Answer 1

It removes the ability of the Factory to say what it should/should not have. No, an interface places no such restriction. What you have is three different problems:
1/how to delegate the instantiation of command objects to command specific mappings.
2/how to load the mappings of command names to the instantiation mechanism at runtime
and now you have
3/ the factory to have a say in what mappings it will support.
1/ is handled perfectly well using interfaces and registry/delegate factory objects; it's convienent to implement these factories as command prototypes, but not necessary, hence there are separate factory and command interfaces.
2/ would be handled by loading the mappings from some data source together with an expression for instantiting the factory instances, together with a controlling registry factory that delegates to the specific factories. One mechanism for this is java.beans.XMLEncoder, or you can hand craft your own restricted version using Class.forName().newInstance. In the above example I didn't do this for you, and created the registry as part of initialising the application.
3/ you've just introduced and you haven't specified what more control you want inside the factory-registery that 1 + 2 don't give you.
I already have the mechanism of telling the Factory what factories it should use to build it's look-up table.So use that mechanism to populate the registry, instead of the test code above.
I suppose an alternative is to have the Factory act as a kind of security manager. This seems to be extra to the previous requirements; what do you want it to do as well as being a factory?
As CommandFactory subclasses are loaded, they create an instance of them, and attempt to register with the top-level CommandFactory to build a look-up or chain of responsibility -- just like your static block. Yes. Though typically I'd use a more flexible mechanism, so that you can load the class without it registering. The static block above in is the class that sets up the application, not the class that implements CommandFactory. If you put the registration code there, then you are forced to have a singleton registry and it becomes tightly bound to one use pattern, and hard to maintain.
Also, when the CommandFactory is instantiated, it can forName all the classes it knows it's looking for to ensure they are loaded.They will be loaded when you create an instance to register. You don't need to do any extra calls to forName. You can use the forName to implement the creation of an instance to register, or you can use the more flexible mechanism built into XmlEncoder. Don't rely on subclasses implementing a particualar registration mechanism, but separate that to a different place. So the only thing that a correct implementation of CommandFactory does is implement a method that creates a command. That way, everything is part of the contract.
...but isn't it bad coding practice to initialize in static code blocks?No. They exist exactly for the purpose of initialising static state; you just have to ensure you don't throw any exceptions and are aware of load-order dependencies. They're also useful for throwaway stuff like the example above, where you want to set up global state for tests rather than writing a full application. But don't use them to do things which are not required to load the class- there's a very big difference between flow of control in the code above and:class EchoCommand extends PrototypeCommand {
  public void execute () {
    System.out.println(args);
  static {
    MB10Command.register.register("echo", new EchoCommand());
class SortCommand extends PrototypeCommand {
  public void execute () {
    List sort = new ArrayList(args);
    Collections.sort(sort);
    System.out.println(sort);
  static {
    MB10Command.register.register("sort", new SortCommand());
public class MB10Command {
  static CommandRegister register = new CommandRegister();
  static {
    new EchoCommand();
    new SortCommand();
  public static void main (String[] args) {
    register.parse(args).execute();
}Because EchoCommand is tied to one particular global registry, it's unusable in any other context, and you end up thinking about adding extra code to overcome the hard coded global variable (otherwise known as singleton anti-pattern).
You also lose the expression of intent- in the previous code, when you load the main class, you explicitly create a registry, then register a couple of prototypes with it. If you start using static blocks so that a side-effect of loading a class is that it registers a prototype with a third party, and then use Class.forName so that registration is a side-effect of a side-effect, you will get very confused very rapidly. Keep both implementation and state as local as possible.
Pete