none
Décoration et Design PatternDecorateur RRS feed

  • Question

  • Bonjour nous réalisons un dictionnaire extenssible.
    Ma modélisation c'est donc orientée sur un parttern composite pour gérer le parcour au sein des têtes de chapitre, chapitre rubrique etc..
    Puis pour assuré l'extenssibilité je me suis basé sur un pattern décorateur.
    j'ai une interface IDico partagé par Mon DiocPerso et son décorateur DicoDeco (classe abstraite qui récupére l'instance du DicoPerso a l'appel de son constructeur).
    Puis j'etend Mon Dico à l'aide de concréte implémentant DicoDeco.

    Lors de la présentation de ma modélisation auprés de l'équipe de dévelloppement je rencontres la rétissance suiante:

    Ils préfère définir une abstraite pour définir les méthodes de base et gérés un liste de Dico concret...
    Du coup on obtient une classe chapeau qui gére la liste des Dicos et reprend l'intégralité des méthodes communes à chaque Dico afin de réorienté l'appel vers le(s) bon(s) dico(s) .

    Et pour le coup c'est moi qui trouve ça moche.

    Moi je trouves ça moche parceque l'on ne respect pas le vieil adage d'un code fermer en écriture mais ouvert en extenssion.

    Eux trouvent l'implémentation Decorateur,ils préfèrent la liste de classe concréte qu'il trouve plus simple...

    C'est donc compléxité structurante contre simplicité pas trops POO.


    Et vous que pensez vous du Design Pattern Décorateur (y a t il des arguments pour vendre la soupe).

    mardi 18 novembre 2008 07:15

Toutes les réponses