Discussion :

[oodini]

Hello,

L'utilisation à gogo du patron Décorateur a-t-elle en sens quand elle est implémentée en statique (avec des templates), par rapport à l'héritage ?

[Emmanuel Deloget]

Hello,

L'utilisation à gogo du patron Décorateur a-t-elle en sens quand elle est implémentée en statique (avec des templates), par rapport à l'héritage ?

Le patron décorateur impose que le type décorateur est compatible avec le type décoré de manière à ce que le premier puisse être utilisé en lieu et place du second, et ce, sans s'en rendre compte au niveau du client. Sans héritage, je ne vois pas comment faire ça.

Tu peux donner un exemple de code ? parce que j'ai du mal à comprendre.

[oodini]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
	** \tparam TP The Threading Policy
	** \tapram Handlers A static list of all message handlers
	** \tparam Decorators A static list of all decorators
	*/
	template<
		class Handlers = StdCout<>,                            // List of all static handles
		class Decorators = Time< VerbosityLevel<Message<> > >, // List of all static decorators
		template<class> class TP = Policy::ObjectLevelLockable // The Threading Policy
		>
	class Logger
		:public TP<Logger<Handlers,Decorators,TP> >, // inherits from the Threading Policy
		public Decorators,                           // inherits from all decorators
		public Handlers                              // inherits from all handlers

Je me rends compte maintenant que ma question est très mal posée, mais voici mon questionnement :

L'intérêt du patron Décorateur est, il me semble, la mise en place d'une relation d'héritage en cours d'exécution. Or, avec une implémentation à base de templates, on se retrouve dans le cas statique. Dès lors, pourquoi ne pas se restreindre à un simple héritage (multiple) ?

[Emmanuel Deloget]

C'est une mauvaise utilisation du patter décorateur, je suspecte même que ça n'en soit pas une du tout et que dans ce cas, Decorator est utilisé pour signifier autre chose.

Le pattern décorateur suppose que si A décore une classe de base B, alors on a les relations suivantes :

* A hérite de B
* A contient un B.

Dans le code que tu postes, on se retrouve avec B qui hérite de ses décorateurs (donc B hérite de A).

Du coup, je me demande vraiment si c'est bien le sens correct pour Decorator dans ce contexte précis. Ca vient d'où ce code ?

[3DArchi]

Salut,

* A hérite de B
* A contient un B.

C'est parce que :
* A vise à être substiuté à B
* B est décoré par A dynamiquement (à l'exécution).
et que l'instance de B est décorrélée de celle de A (durée de vie).

Faudrait voir l'utilisation dans la classe mais ce n'est peut être qu'une autre policy