Design pattern Navigation

Bonjour à tous,

Je travail actuellement sur un jeu avec slick.
J'aimerais faire une belle gestion des options avec enchainement d'écran, next, back, annuler, sauvegarder, ...
Je me demande quel designs patterns je pouvais utiliser pour réaliser cela parceque mon premier essaie "à l'arrache" n'est vraiment pas maintenable.

Un peu plus de détail :
J'ai une classe par écran : MainMenu, GeneralOption, SoundOption,...
Chaque classe hérite d'Entity et doivent redéfinir les méthodes update(...) et render(...).

Enfin j'ai ma classe principal qu'on appellera Main qui appelle en continue (toutes les x ms) update et render de l'écran concerné et uniquement l'écran concerné (MainMenu ou GeneralOption ou SoundOption,...).

J'avais pensé au pattern Command et State mais il y a peut être plus simple :?

Sémentiquement Command et State serait la solution à considérer
Juste un petit truc comme ça as-tu pensé a utiliser le concept de pipes and filter pour l'objet affecté par les choix utilisateurs ?

Choix1--->pipe transportant l'objet -->filter modifiant l'objet/ les choix de l'écran suivant

M'enfin peut-être trops complexe... signe que je suis en fase architecture

Annulation
Pattern Undoable Command :
une interface Commandes avec les méthodes do(), isUndoable(), undo() (et redo() ?).
une classe abstraite AbstractCommand avec isUndoable() renvoie false, undo (et redo()) lance une UnsupportedOperationException.
Chaque commande défaisable doit avoir une qui lui est opposée "créer" -> "détruire", "modifier" -> "modifier", etc.
Chaque commande défaisable stocke le(s) identifiant(s) de(s) objet(s) concerné(s) et des paramètres.
Sur l'appel de la méthode "do()", tu stockes les valeurs actuelles et tu crées la commande opposée ou tu stockes les paramètres de la commande opposée, ensuite tu exécutes l'action
=> A voir pour gérer ça avec une nouvelle sous-classe abstraite AbstractUndoableCommand

NB : On peut traiter les commandes "undo", "redo", "repeat" comme des Commandes

Navigation
Une pile de commande "Affiche" devrait le faire :)

Sauvegarder
Je vois pas trop ce à quoi tu t'attends ?_?

Merci pour vos réponses,

@Nemek, j'ai énumérer "next,back,sauvegarder,... " pour signifier que j'aurais plusieurs boutons c'est tout :aie:
"Sauvegarder
Je vois pas trop ce à quoi tu t'attends ?_?" Moi je sais, c'est le principal :aie:
Je ne pense pas que j'aurais besoin de partir dans un Undoable Command , une fois les options de jeu modifiées ont ne peux plus faire marche arrière (à part un reset)

@laurent_m, Attend! tu va trop vite, tu m'as perdu dès la deuxième phrase :aie:. Pipes, filter,... jamais entendu parlé sorry. Je vais partir sur State et Command tranquilement.

Merci à vous deux, j'avais juste besoin d'une confirmation en fin de compte :aie:.

Me restera la partie "complexe" à savoir qu'il n'y a qu'une seul classe qui est update(..) mais il peut y avoir plusieurs classe render(..) (exemple : dessine[render] le jeu puis dessine le menu pause (transparent), mais seul le menu pause est intéragible[méthode update] (pas français désolé) ).

Il faut aussi que je revoie le pattern state que je n'ai utilisé que 2 fois :?

Ok, désolé j'étais à côté de mes pompes hier :aie:

J'essayes de reprendre ...
Annuler / Sauvegarder
Si j'ai bien compris c'est "afficher" la configuration actuelle ou bien "appliquer" la configuration sélectionnée ?

Je ferais un "écran" générique avec des méthodes setData(T data), apply(), revert().

• setData() permet de spécifier l'objet Java qui va contenir les données, ca peut un POJO, un controlleur. Tu peux également remplacer cette méthode par le constructeur ou bien passé data aux deux autres méthodes.
• apply() modifie data avec les données saisies (lance éventuellement des notifications)
• revert() modifie l'écran avec les données de data.

Navigation
Une state machine est clairement le "must do":

• Un état représente un écran.
• Un sous-état ou les états-concurrents permettent de représenter des parties dynamiques d'un écran
• Une transition symbolise le lien entre les écrans
• L'action/événement d'une transition symbolise l'action/le bouton qui permet de passer à l'écran cible de la transition
• Les gardes symbolisent les règles de navigation (ex : confirmation avant de quitter un écran qui contient des modifications non appliquées)

Update / render
J'utiliserai un modèle événementiel avec gestion d'un delta temporel minimum pour rafraîchir l'interface plutôt que "tous les x ms"

OK message reçu, je passe en "résolu", vous avez bien joué vos rôles :D.
Merci à vous

Citation:

---

Update / render
J'utiliserai un modèle événementiel avec gestion d'un delta temporel minimum pour rafraîchir l'interface plutôt que "tous les x ms"

---

Slick s'occupe déjà de tout, un delta est déjà disponible ;).