Décorateur est utilisé quand on veut greffer une gamme de comportements optionnels et cumulatifs à une classe de base. Utiliser l'héritage pur serait peu pratique, car on devrait écrire autant de sous-classes que de combinaisons de comportements possibles.
Le style de code qui découle de l'utilisation de Décorateurs peut paraitre répétitif car il reflète cette cumulativité. Pour autant, on n'est pas obligé de déclarer toutes les variables intermédiaires, on peut avoir :
Chevalier c = new DecorateurEpee( new DecorateurBouclier( new Chevalier()));
A la base, le pattern Décorateur ne transforme pas un objet au runtime, parce qu'on n'en a pas vraiment besoin. Comme tu le dis, soit la classe cliente a une référence précise vers un objet décoré et n'aura jamais besoin de le re-décorer (90% des cas d'après mon expérience), soit s'il change, on lui repasse une nouvelle instance. Par contre, c'est inexact de dire que l'objet décoré est une instance totalement différente, car il contient une référence à l'objet d'origine, et non une copie de celui-ci.
Ton système est plus dynamique et, peut-être, plus adapté pour un jeu où l'objet Chevalier va être transformé au cours du temps, acquérant des armes, des pouvoirs, subissant des effets... Mais ce n'est pas un Décorateur. Et il est aussi plus "dangereux", plus complexe et plus difficile à debugger puisqu'on peut ajouter et retirer à loisir des décorations. On peut être confronté à des situations compliquées lorsque plusieurs clients essaient de décorer / dé-décorer le même objet dans le même laps de temps.
Partager