Forum Programmation.autre Patron de conception monteur cohérence des objets montés

Posté par  .
Étiquettes : aucune
0
6
oct.
2009
Bonjour,

ceci est une question théorique et scolaire.

Le patron de conception Monteur_(patron_de_conception) permet de déléguer la construction d'un objet à des classes tierces, appelées les classes monteuses.

Exemple, création d'une instance de voiture dans un jeu vidéo : la classe MonteurVoiture va successivement définir les paramètres de jeu de la Voiture, ses éléments graphiques,ses éléments sonores, etc...

Le souci, c'est que du coup, durant sa phase de montage, l'objet n'est pas encore complètement initialisé.
Par conséquent, si le jeu appelle maVoiture.demarrer() alors que le moteur n'est pas encore instancié,... il va y avoir un problème.

D'où ma question :

existe-t-il un patron de conception, ou tout au moins une bonne pratique, communément utilisée, pour gérer l'état des objets manipulés ?

Par exemple notifier les autres composants de l'évolution de l'état d'un objet, ou encore verrouiller certaines méthodes de l'objet tant que certaines conditions d'état ne sont pas remplies.

En espérant que ma question est claire, merci d'avance.

  • # Plusieurs méthodes

    Posté par  (site web personnel) . Évalué à 2.

    Tu peux utiliser un statut interne à ta classe indiquant dynamiquement :
    EN_COURS_DE_MONTAGE = 0
    PRET_A_DEMARRER = 1
    DEMARRE = 2

    et utiliser ce statut pour lors de l'appel de la méthode démarré :

    SI( statut() <> PRET_A_DEMARRER ) Alors Quitter
    Sinon
    Demarrer
    Fin Si



    Autre solution, utiliser les asserts. Ce qui force la personne qui utilise tes classes à les utiliser correctement dés le début.

    Methode démarré :
    ASSERT( moteur() != null )
    ou
    ASSERT( statut() == PRET_A_DEMARRER )
    Demarrer


    Dans le cas d'un assert l'application plante, s'il n'est pas écrite correctement avec un message du genre (assert failure (moteur() !=null) at line ... in file ....)

    • [^] # Re: Plusieurs méthodes

      Posté par  . Évalué à 1.

      Ou utiliser un mutex.

      Tand que la voiture est en construction, le mutex est vérouillé donc pas de démarrage ...

      • [^] # Re: Plusieurs méthodes

        Posté par  . Évalué à 3.

        je vais paraitre stupide surement (je ne suis pas developpeur) mais avec une programmation objet, une voiture herite des fonctions des classes precedentes (roues, moteur....)

        je ne sais plus comment ca s'ecrit, mais ensuite si tu fais...
        if (mycar=new car())
        then mycar->start()

        l'appelle à new car() va aller chercher un moteur, des roues, des sieges
        et te renverras mycar uniquement quand ce sera fini

        non ?

        • [^] # Re: Plusieurs méthodes

          Posté par  . Évalué à 2.

          Ce que tu dis est juste, dans le cas général.

          Mais parfois, en pratique, c'est plus compliqué. La création d'un objet ne se résume pas toujours à faire un new MaClasse().

          Par exemple, dans un jeu vidéo de voitures, le développeur n'écrit probablement pas une énorme classe Voiture qui gère toutes les configurations imaginables (avec plein de paramètres). Il n'écrit probablement pas non plus une classe par configuration imaginable.
          En fait, il va surtout s'appuyer sur des bibliothèques de moteurs, de roues, de skins, de sons, etc..., qu'il ne connaît généralement pas (il ne connaît que leur interface).
          Il va seulement écrire un classe Monteur, qui contient une série de fonctions, chacune étant chargée de créer un élément précis.

          Le ''directeur'' (celui qui donne les ordres, ici le jeu vidéo) appelle le monteur, qui va créer une Voiture ''vide'' (new Voiture()). Puis, il appelle tour à tour chacune des fonctions du monteur. Une fois qu'il les a toutes appelées, la voiture est prête à l'usage. Et donc là seulement, tu peux faire maVoiture.demarrer().

          En milieu de montage, d'un point-de-vue objet pur, maVoiture est bien une instance de Voiture. Mais une instance seulement à moitié initialisée.

          Et lorsque l'état de l'assemblage d'un objet dépend de celui d'un autre, ça peut vite devenir le bazar.

          D'où ma question : existe-t-il une bonne pratique pour décrire l'état d'avancement de la construction des objets ?

          Je pensais aux par GRAFCET, dont ont peut lier la progression à l'aide de bits de synchronisation. Peut-être existe-t-il un équivalent en modélisation orientée objet.

          • [^] # Re: Plusieurs méthodes

            Posté par  . Évalué à 3.

            Il y a le pattern observateur qui peut rendre ce type de service. Ton directeur s'inscrit auprès de ton monteur comme observateur. Quand le monteur a fini son travaille, il signale à ses observateurs (donc au directeur) qu'il a terminé. Le directeur peut donc démarrer la voiture.

            • [^] # Re: Plusieurs méthodes

              Posté par  . Évalué à 2.

              Cela résout effectivement le problème dans le cas de l'utilisateur cherche à utiliser proprement la classe instanciable par montage.

              Mais contrairement à certaines solutions proposées plus haut, ça ne permet pas de verrouiller l'objet en cours de montage.

              • [^] # Re: Plusieurs méthodes

                Posté par  . Évalué à 2.

                reste la solution du verrou, mutex, flag...

                ton module de construction :
                flag = 1
                debut de construction
                construction()
                fin de construction
                flag=0

                ton module demarrer :

                si flag=0 //construction terminé
                alors demarre()

  • # Peut-être HS ...

    Posté par  . Évalué à 2.

    Mais j'aurais dit RAII.
    Ça ne va pas vraiment t'aider, puisque ça a l'air un peu incompatible avec le Builder, mais c'est quelque chose qui marche bien en général.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.