Using Objects to Initialize Static Fields: Good or Bad
I have a Command interface and a bunch of Commands that implement it (i.e. CmdJoin,CmdQuit). These Commands' settings change at runtime (i.e. required access levels, String identifiers). I don't want to have to store an instance of each Command in a database to save their settings , so instead I'm using the obvious solution: making static fields in these commands for these settings. This way, I can use a Simple Factory to return a Command, change its settings, execute it, and forget it, and still have the settings for that Command apply to all Commands. Yet I want to be able to modify and access fields of different Commands polymorphically. How can I have these commands' settings-related fields be static while modifying and accessing these fields polymorphically?
Here's what I have though of. First of all, interfaces can't have static methods. Secondly, neither can abstract classes. I also can't extend a base class which implements these settings-related fields and their interface, because then the fields would belong to all child classes of this base class, whereas I just want it to belong to a certain child class of the base class (i.e. all instances of CmdJoin or CmdQuit).
I've thought of two solutions.
The first is implementing a concrete interface in an abstract base class (getting rid of the Command interface) and overriding it in child classes, so that I can use the interface of the base class and the fields of the child classes.
The second is having no base class, and just a bunch of Commands implementing the interface with their own static fields. I would initialize these fields by passing arguments to their constructors.
These solutions seem very sloppy though! Are there any better ways?
