Problème de design OO pour implémenter un automate fini

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Salut tout le monde ! On à un petit projet à faire pour les cours, un parseur XML. Tout se passe bien mais on à juste un problème, on ne sait pas ou mettre la logique concernant la création des noeuds XML.

En fait on à un automate fini qui lit et valide le fichier. Une autre classe avec un buffer de texte qu'on remplie à la volé et ensuite en fonction de l'état de l'automate on dit à cette classe quoi faire avec le buffer (créer un nouveau nœud, rajouter du contenu à un nœud, fermer un nœud etc…)

Diagramme de classe

Question :

Ou et comment appeler les méthodes de la classe qui s'occupe de crée les nœuds. Est-ce que ce serait une erreur de design si on remplissait le buffer etc… directement dans les états de l'automate ?

+0 -0
Staff

Déjà ça m'a l'air ultra-compliqué comme design de classe.

Généralement tu peux modéliser ton automate (s'il n'est pas trop compliqué) par une seule classe, l'état est interne (éventuellement lisible), et tu as une méthode par transition. L'état peut être soit implicite (représenté par l'objet lui-même), soit explicité (par exemple représenté par la valeur d'un enum).

Auteur du sujet

Donc ce que tu proposes c'est qu'on remette toute la logique des états dans l'automate lui même ? Ça nous fais une classe bien chargée quand même.

C'est notre prof qui nous à dit d'utiliser ce design. Ça tourne bien mais c'est vrai que je ne vois pas comment aller plus loin proprement.

Pour expliciter un peu plus :

Design de base

L'automate boucle en appellant la méthode évoluer qui change l'état courant avec la méthode récupérer événement. Moi je le trouve pas si mal que ça.

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte