problème de conception de génériques java (machine à états)

J’ai créé une machine à états et j’aimerais qu’elle tire parti des génériques en java. Actuellement, je ne vois pas la façon dont je peux faire ce travail et obtenir joli code. Je suis sûr que ce problème de conception a déjà été abordé à maintes resockets et je cherche des idées. Heres une ébauche.

class State { ... } 

une seule copie de chaque object d’état distinct (principalement des classes anonymes liées à des variables finales statiques), des données personnalisées sont associées à chaque état. chaque object d’état a un parent d’état (il y a un état racine)

 class Message { ... } 

chaque message est créé séparément et chacun a des données personnalisées. ils peuvent se sous-classer. il existe une classe de message racine.

 class Handler { ... } 

chaque gestionnaire est créé une seule fois et traite d’un combo spécifique d’état / message.

• Différence entre le motif de décorateur et le modèle de délégation
• Problème de modèle de conception impliquant N états et transitions entre eux
• Paramètre de méthode multi-types Java?
• Existe-t-il un moyen recommandé d’utiliser le modèle Observer dans MVP en utilisant GWT?
• Une connexion à la firebase database doit-elle être un singleton?

 class StateMachine { ... } 

conserve actuellement une trace de l’état actuel et une liste de tous ( State , Message ) -> Handler . il a également d’autres fonctionnalités. J’essaie de garder cette classe générique et de la sous-classer avec des parameters de type car elle est utilisée plusieurs fois dans mon programme, et à chaque fois avec un ensemble différent de Message / State / Handler . différents StateMachine auront des parameters différents pour leurs gestionnaires.

Approche A

demander à la machine d’état de suivre tous les mappages.

 class StateMachine { static class Delivery { final State state; final Class msg; } HashMap delegateTable; ... } class ServerStateMachine extends StateMachine { ... } 

me permet d’avoir des méthodes de gestionnaire personnalisées pour cette machine à états particulière. les parameters de la méthode handler.process peuvent être remplacés. Cependant, le gestionnaire ne peut pas être paramétré par le type de message.

Problème: cela implique l’utilisation du contrôle d’ instanceof pour chaque gestionnaire de message (s’assurer qu’il reçoit le message qu’il attend).

Approche B

permet de paramétrer chaque gestionnaire de message par type de message

 class MessageHandler { void process(M msg) { .... } } 

Problème: l ‘ effacement de type m’empêchera de les stocker dans un joli hashmap puisque tous les MessageHandler seront typés différemment. si je peux les stocker dans une carte, je ne pourrai pas les récupérer et les appeler avec les arguments appropriés.

Approche C

avoir l’object state gérer tous les messages.

 class State { ... } class ServerState extends State { ... } 

J’ai des gestionnaires de messages liés à des états spécifiques de la machine à états (en les plaçant à l’intérieur) (chaque instance d’une machine à états aurait sa propre liste d’états valides), ce qui permet aux gestionnaires d’être d’un type spécifique. (machine d’état du serveur -> gestionnaire de messages du serveur).

Problème: chaque état ne peut gérer qu’un seul type de message. vous perdez également l’idée que l’état parent peut gérer différents messages que les états enfants. type erasure empêche également StateMachine d’appeler des méthodes de traitement d’états en cours.

Approche D

avoir le processus du message eux-mêmes basé sur l’état.

Problème: jamais vraiment pris en compte, car chaque message devrait avoir un gestionnaire différent basé sur l’état actuel de la machine à états. l’expéditeur ne connaîtra pas l’état actuel de StateMachine .

Approche E

oubliez les génériques et la gestion de l’état / message du code dur avec une instruction switch.

Problème: santé mentale

Solution dangereuse:

Merci pour votre consortingbution tout le monde, je pense que le problème était que je ne l’ai pas réduit à bon problème (trop de discussion) voici ce que j’ai maintenant.

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

• Pourquoi la logique métier doit-elle être retirée de JSP?
• Pourquoi utiliser l’interface dans le modèle de conception Dao ou d’autres modèles de conception
• Avantages et inconvénients du chaînage de méthodes et possibilité de remplacer tous les parameters de retour vide par l’object lui-même
• Motif Singleton avec une combinaison de chargement paresseux et de sécurité du fil
• Système simple de dissortingbution de messages Java

 interface Handler { ...} interface Message {...} interface HandlerContainer {  void register(Class clazz, Handler handler);  Handler getHandler(T t); } class HandlerContainerImpl implements HandlerContainer { private final Map,Handler> handlers = new HashMap,Handler>();  void register(Class clazz, Handler 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")  Handler getHandler(T t) { return (Handler)handlers.get(t.getClass()); } } 

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

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

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

 class OtherState { public double x1; public int i; } enum MyState extends StateMachineState { 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; } }, } 

 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 */ }