Des développeurs qui n'aiment pas la décoration?

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 complexe,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.

Bonjour,

Citation:

---

reprend l'intégralité des méthodes communes à chaque Dico

---

Ce qui me gène dans leur solution c'est que certains Dico vont implémenter des méthodes qu'ils n'utiliseront pas...(si j'ai bien compris)
Ta solution me semble cohérente, un lien qui leurs permettra de mieux comprendre : http://www.design-patterns.fr/Decora...-vente-de.html

Le pattern decorateur est puissant mais sa récursivité implicite le rend difficile à appréhender. C'est ce qui risque de déstabiliser un peu les développeurs pour leur faire préférer une implémentation plus lisible même si elle a le défaut d'étre plus compliquée.
Pour autant que vos à priori soient fondés, essayez de leur montrer les avantages de votre approche dans les aspects "construction", "tests", "évolution" (comparée à celle qu'ils semblent préférer).

-W

Comme tu l'expliques, je reste à la solution de la récursivité, mais faut il absolument un concept objet pour traité la récursivité, ça me laisse un peu perplexe en considérant les performances de ton appli.

Je ne comprends la solution qu'ils préconisent.

Il y a aussi une autre question de design souleve par ce pattern:

Est-ce que la nouvelle responsabilite que tu veux rajouter, s'applique a toutes les instances de ta classe ou seulement a quelques instances.

• Si elle s'applique a toutes les instances: la facon standard d'ajouter une nouvelle responsabilite est de la faire implementer par la classe.
• Si tu veux etendre la responsabilite de certaines instances seulement, le dp decorateur te le permet.

En me posant cette question, dans la majorite des cas, la responsabilite concerne la classe. Le design est simplifie, parce que tu n'as pas cette "recursion", qui fait que pour savoir ce que peut faire un objet, tu es oblige de savoir comme il a ete construit a l'execution.

Euh si j'ai bien compris, DicoDeco sert à ajouter des méthodes de recherche dans le dictionnaire DicoPerso, c'est bien cela ? Ou alors je n'ai pas compris et il faut m'expliquer ;) si ce n'est pas trop tard bien sûr...