Sorry for the delay in the reply.. good to know you are here as
I recognise that name..
Try not to design in terms of enums, but in terms of interfaces. If
the implementation ends up looking like an enum, then sure, for
clarity, make it an enum.
In this example, I would have something like:
interface MajorCommand
{
Iterable<SubCommand> possibleValues();
}
interface SubCommand
{
}
enum Commands
{
LOGON
{
public Iterable<SubCommand> possibleValues()
{
return Collections.emptySet();
}
},
QUIT
{
public Iterable<SubCommand> possibleValues()
{
SubCommand[]
subCommands=QuitSubCommands.values();
return Arrays.asList(subCommands);
}
},
LIGHT
{
public Iterable<SubCommand> possibleValues()
{
SubCommand[]
subCommands=LightSubCommands.values();
return Arrays.asList(subCommands);
}
}
}
enum QuitSubCommands
{
IMMEDIATELY,
DELAY
}
enum LightSubCommands
{
TURN_ON,
TURN_OFF
}
unomystEz wrote:
I have a protocol structure that makes use of subcommands and I was
wondering if it's possible to do something like the following:
public enum MajorCommand {
LOGON { public enum SubCommand { }; }
QUIT { public enum SubCommand { IMMEDIATELY, DELAY }; }
LIGHT { public enum SubCommand { TURN_ON, TURN OFF}; }
public abstract enum SubCommand;
}
It would help a lot with the organization of the various combinations
possible.