[Décorateur] Peut-on se passer de la classe abstraite Decorator ?

[hgsdhgsd]

Bonjour,

Je me pose quelques questions concernant le patron Decorator et plus particulièrement sur l'utilité la classe abstraite Decorator qui intervient dans ce patron.

Dans le pattern Decorator (GoF 175) interviennent :

Component
ConcreteComponent
Decorator
ConcretDecorator

Le GoF, page 179 (deuxième point de la section implementation, "Omitting the abstract Decorator class"), dit que cette classe ne peut être omise que lorsqu'on a besoin d'ajouter une "responsabilité" en plus. Mais je ne vois pas pourquoi elle est nécessaire même si on doit ajouter plus d'une "résponsabilité".

En effet, cette classe ne semble que rendre obligatoire la définition de méthode déjà rendu obligatoire par Component. De plus, le typage est assuré par l'héritage de Component, donc Decorator ne joue pas de rôle de ce point de vue. Et, si un décorateur concret à besoin d'une méthode spécifique alors elle n'a pas à se trouver dans la classe abstraite Decorator puisque ça serait une erreur de l'appeler sur un autre décorateur concret. Bref, Decorator ne semble que répéter ce que Component dit déjà, est-ce le cas ?

Les questions que je me pose :

La classe abstraite (ou l'interface) Decorator est-elle vraiment nécessaire ?

Pourquoi les "décorateurs concrets" ne pourraient-ils pas être des sous-classes "directes" de Component, et stocker eux-même une référence vers Component ?

Pourquoi ne pas supprimer l'intermédiaire qu'est la classe abstraite Decorator ?

Avez-vous des exemples d'utilisation du pattern Decorator qui ne sont pas réalisable sans une classe abstraite Decorator, c'est-à-dire des exemples où il est impossible de faire l'hériter directement les décorateurs concrets de Component ?

La seule utilité de cette classe est-elle de clarifié la structure du programme ?

Vous l'aurez compris, j'ai du mal à comprendre l'utilité d'une classe abstraite Decorator et je dois avouer qu'une interface java Decorator me semble encore moins utile du fait qu'elle ne peut pas stocker de variables, pas même la référence vers Component, ni de définitions que se partageraient les sous-classes (car j'ai lu que certains préconisaient en java l'utilisation d'une interface java plutôt qu'une classe abstraite). Tout ce questionnement est surement du à mon inexpérience, mais j'aimerais comprendre ce qui m'échappe.

Merci.

hgsd.