views:

387

answers:

5

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;
  }

}
+2  A: 

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);
  }
}
Zed
Don't see the need for/benefit from generics too. I'd keep the code readable and understandable rather then pretty.
Andreas_D
the problem is that each state machine instance has its own *type* of handlers (the handlers have different method signatures). this can be done by subclassing the state machine. however, i would like to write each handler to be also so they accept a specific message type, rather than just a message class, and then casting / instanceof'ing
aepurniet
I'm not sure I completely understand the problem... but I added a scheme of what I am thinking of. It surely misses handlers, but those probably can be added in a similar manner.
Zed
im just trying to avoid writing the boiler plate code to switch between the custom cases (potentially up to one per message type) (as noted in your CustomState.handle method), by writing specific handlers that take the actual type of the Message object, rather than the Message object and going through instanceof, casting hell.
aepurniet
Sorry, that was a bug in the code. It should take the CustomMessage of course.Anyway, I think there are two ways to go: you either have to have "boilerplate code", or have to have a common interface which all your classes adhere to.Maybe someone will prove me wrong.
Zed
+2  A: 

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.

Michael E
A: 

Approach F:

Forget about generics unless you have type-specific patterns. Define a couple of interfaces per your desired system, including perhaps something like

interface StateMachineState<R extends StateMachineState,T> {
    /* returns next state */
    R execute(T otherState); 
}

and for a particular state machine, use enums that extend StateMachineState:

class OtherState {
    public double x1;
    public int i;
}

enum MyState extends StateMachineState<MyState,OtherState>
{
    FOO {
       MyState execute(OtherState otherState) { 
           otherState.x1 += 3.0;
           otherState.i++;
           return BAR;
       }
    },
    BAR {
       MyState execute(OtherState otherState) { 
           otherState.x1 -= 1.0;
           otherState.i--;
           return (i % 3 == 0) ? FOO : BAR;
       }
    },         
}

Then you can do something like:

MyState state = MyState.FOO;
OtherState otherState = new OtherState();
otherState.i = 77;
otherState.x1 = 3.14159;
while (true)
{
    state = state.execute(otherState);
    /* do something else here */        
}

(caveat: code not double-checked for syntax errors)

Jason S
+1  A: 

The approach I have seen in a few places, is to use annotations. Use regular POJO classes and annotate them to be processed by a manager type class which runs the state machine:

public class MyState {
 @OnEntry
 public void startStuff() {
  ...
 }

 @OnExit() 
 public void cleanup() {
  ..
 } 
}

There are a few more developed implementations, I think the Scientific Toolbox one was good but I cant find the right link now: http://mina.apache.org/introduction-to-mina-statemachine.html http://weblogs.java.net/blog/carcassi/archive/2007/02/finite%5Fstate%5Fma%5F1.html http://hubris.ucsd.edu/shared/manual.pdf

Justin
i really like this one the more i think about it, each annotation could have the message class as a parameter, and with some reflection, could be processed properly. if a declared method is not found that matches the message class, the message can be passed up to the parent state.
aepurniet
+1  A: 

For approach B, don't use a "nice" hashmap. Instead, write a heterogenous typesafe container mapping handlers to Class objects:

interface Handler<T extends Message> {
...}


interface Message {...}

interface HandlerContainer {

    <T extends Message> void register(Class<T> clazz, Handler<T> handler);

    <T extends Message> Handler<T> getHandler(T t);

}


class HandlerContainerImpl implements HandlerContainer {

    private final Map<Class<?>,Handler<?>> handlers = new HashMap<Class<?>,Handler<?>>();

    <T extends Message> void register(Class<T> clazz, Handler<T> handler) {
          if (clazz==null || handler==null) {
             throw new IllegalArgumentException();
          }
          handlers.put(clazz,handler);
    }

    //Type safety is assured by the register message and generic bounds
    @SuppressWarnings("unchecked")
    <T extends Message> Handler<T> getHandler(T t) {
            return  (Handler<T>)handlers.get(t.getClass());

    }

}
this is what i wound up using, seems like that pattern is the way to go to solve most type erasure problems. i really like justin's annotation answer also, both seem to handle the problem properly. this one doesnt use reflection, which makes it slightly cleaner, although it involves typing more to register each handler. i wound up using reflection to register the handlers anyway.
aepurniet