java generics design problem (state machine)

Question

i made a state machine and would like it to take advantage of generics in java. currently i dont see the way i can make this work and get pretty looking code. im sure this design problem has been approached many times before, and im looking for some input. heres a rough outline.

class State { ... }

only one copy of each distinct state object (mostly anonymous classes tied to static final variables), it has custom data for each state. each state object has a state parent (there is one root state)

class Message { ... } 

each message is created separately and each one has custom data. they may subclass each other. there is one root message class.

class Handler { ... } 

each handler is created only once and deals with a specific state / message combo.

class StateMachine { ... }

currently keeps track of the current state, and a list of all (State,Message) -> Handler mappings. it has other functionality as well. i am trying to keep this class generic and subclass it with type parameters as its used a bunch of times in my program, and each time with a different set of Message's / State's / and Handler's. different StateMachine's will have different parameters to their handlers.

Approach A

have the state machine keep track of all mappings.

class StateMachine<MH extends MessageHandler> {
  static class Delivery {
    final State state;
    final Class<? extends Message> msg;
  }
  HashMap<Delivery, MH> delegateTable;
  ...
}

class ServerStateMachine extends StateMachine<ServerMessageHandler> {
  ...
}

allows me to have custom handler methods for this particular state machine. the parameters for the handler.process method can be overwritten. However, the handler cannot be parameterized by the message type.

Problem: this involves using the instanceof sanity check for each message handler (making sure it is getting the message it is expecting).

Approach B

lets make each message handler parameterized by message type

class MessageHandler<M extends Message> {
  void process(M msg) { .... }
}

Problem: type erasure will prevent me from storing these in a nice hashmap since all the MessageHandler's will be typed differently. if i can store them in a map, i wont be able to retreive them and call them with the proper arguements.

Approach C

have the state object handle all messages.

class State<M extends Message> { ... }
class ServerState<M extends ServerMessage> extends State<M> { ... }

i have message handlers tied to specific state machine states (by putting them inside), (each instance of a state machine would have its own list of valid states), which allows the handlers to be of a specific type. (server state machine -> server message handler).

Problem: each state can only handle one message type. you also lose the idea that parent state's can handle different messages than child states. type erasure also prevents the StateMachine from calling current states process methods.

Approach D

have the message's process themselves based on state.

Problem: never really considered, since each message should have a different handler based on the current state machine state. the sender will not know the current StateMachine's state.

Approach E

forget about generics and hard code state / message handling with a switch statement.

Problem: sanity

Unsafe Solution:

Thanks for your input everybody, i think the problem was i did not reduce this to good problem (too much discussion) heres what i have now.

public class State { }

public class Message { }

public class MessageHandler<T extends Message> { }

public class Delivery<T extends Message> {
  final State state;
  final Class<T> msgClass;
}

public class Container {

  HashMap<Delivery<? extends Message>, MessageHandler<? extends Message>> table;

  public <T extends Message> add(State state, Class<T> msgClass, MessageHandler<T> handler) {
    table.put(new Delivery<T>(state, msgClass), handler);
  }

  public <T extends Message> MessageHandler<T> get(State state, T msg) {
    // UNSAFE - i cannot cast this properly, but the hashmap should be good
    MessageHandler<T> handler = (MessageHandler<T>)table.get(new Delivery<T>(state, msg.getClass()));
    return handler;
  }

}

Answer 1

E with enums representing states and messages is probably the easiest. But it is not very extensible.

C using the Visitor pattern in the state classes to dispatch on message type looks like it may be the best of your options. Given a choice between instanceof and Visitor, I think Visitor is slightly cleaner (albeit still awkward). The type erasure problems do pose a notable difficulty, and processing in the message seems somewhat backwards. Typical state machine notation has the states as the center of control. Further, you can have the Visitor abstract class for the message types throw an error on all states, thus allowing states to get error fall-back on invalid messages for free.

C+Visitor would be quite analogous to the approach I frequently use when implementing state machines in C or languages with first-class functions -- "state" is represented by a pointer to the function handling messages in the current state, with that function returning a pointer to the next state function (possibly itself). The state machine control loop merely fetches the next message, passes it to the current state function, and updates the notion of "current" when it returns.

Answer 2

Approach E. Forget about generics, and use interfaces.

class Message { ... }
class State { ... }

class Machine {
  static State handle(State current, Message msg) {
    ...
  }
}

class CustomMessage extends Message { ... }
class CustomState extends State { ... }

class CustomMachine {
  static CustomState handle(CustomState current, CustomMessage msg) {
    // custom cases
    ...

    // default: generic case
    return Machine.handle(current, msg);
  }
}