Forum Programmation.c++ Débat : conception objet

Posté par  .
Étiquettes : aucune
0
8
sept.
2007
Bonjour,
ce débat est dans la lignée des Design Pattern donc à voir avant de répondre :-)

voila le projet. J'ai une classe abstrait Forme qui caractérise un objet graphique et à chaque objet j'associe un objet concret ToolManipulator qui dérive d'une classe abstraite Tool. Donc tout fonctionne bien mais j'ai deux choix qui s'offre à moi :
* l'objet Forme sait construite un objet ToolManipulator adapté à l'objet à manipuler sur l'écran mais cela oblige à modifier chaque classe concrete Forme pour changer un comportement mais une possibilité de création de nouvelles Formes par "pluging" est facilement réalisable par chargement de bibliothèques dynamiques
* autre solution : faire comme pour la fabrique de mes objets Forme et faire un objet Fabrique qui sera le seul à construire le "ToolManipulator" en fonction de l'objet à manipuler. Intérêt : je n'ai pas besoin de toucher aux Formes pour modifier un comportement

Quelqu'un a déjà fait ce genre de chose ? quels sont les autres avantages /inconvénients de ces deux approches ?

Merci de vos réponses et bonne réflexion

  • # heritage et ces amis...

    Posté par  . Évalué à -2.

    rappel de mes notions de programmation objet

    soit un objetA avec des methodesA1,A2,A3

    soit un objetB derivé de objetA et avec les methodes B1,B2,B3

    l'objetB disposera donc de 6 methodes
    A1,A2,A3 par heritage
    B1,B2,B3 par definition.

    mais rien n'empeche de "surcharger" une methode de A dans la definition de B pour avoir un comportement specifique à B

    • [^] # Re: heritage et ces amis...

      Posté par  . Évalué à 2.

      Merci mais cela n'a rien à voir avec la réponse attendue. De plus les méthodes B1,B2,B3 ne pourront pas être utilisée par le programme qui utilise l'objet Tool car sinon cela suppose que l'on soit obligé de modifier le code pour traiter des cas spécifiques ce qui va à l'encontre du design ici présenté. Une bonne connaissance des design patterns est ici souhaitée pour discuter des avantages des 2 conceptions proposée.

  • # quelques definitions pour essayer de comprendre

    Posté par  . Évalué à 0.

    "design pattern" :
    http://fr.wikipedia.org/wiki/Design_pattern

    une exemple en java :
    http://abrillant.developpez.com/tutoriel/java/design/pattern(...)

  • # Fabrication

    Posté par  . Évalué à 2.

    La première approche est la plus simple. Elle correspond au pattern Fabrication (Factory Method, en vo).
    Mais, quand tu dis "cela oblige à modifier chaque classe concrète Forme pour changer un comportement", quel problème cela te pose ?

    • [^] # Re: Fabrication

      Posté par  . Évalué à 2.

      Merci de la réponse.L'avantage de la seconde méthode est de pouvoir modifier les outils sans toucher à la forme associée et l'intérêt de la première est de pouvoir faire des plugins pour chaque nouvelle Forme plus facilement. Je voulais savoir surtout ce qui était fait dans les bibliothèques existantes. Sinon au sens POO et OCP les deux conceptions sont bonnes.
      Cordialement

      • [^] # Re: Fabrication

        Posté par  . Évalué à 2.

        Ben tu fais comme il faut le faire avec les motifs de conception : tu les mets côte à côte, notamment les parties conséquences et problèmes, et, en plus de regarder ce qui est plus facile pour le moment, tu évalues suivant ce que tu penses qu’il pourrait arriver à ton programme, ses évolutions futures.

        (Perso, je préfèrerais Factory : sinon, une forme est liée à un outil et, plus on vieillit, moins on aime les liens…)

      • [^] # Re: Fabrication

        Posté par  . Évalué à 1.

        Ca dépend de tes besoins en fait. Pour faire simple :
        - Soit une Forme peut être manipulée par plusieurs ToolManipulator différents auquel cas il vaut mieux centraliser la gestion et la configuration dans une Fabrique.
        - Soit à une Forme est associée un ToolManipulator et lorsque tu code ta Forme, tu code aussi ton ToolManipulator (ou tu en réutilise un existant) et je pense qu'il vaut mieux que le Tool construise son ToolManipulator.

        Cordialement

Suivre le flux des commentaires

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