Discussion :

[Trunks]

A la fin du tutoriel, il y a cette citation:

En pratique, on chaîne souvent les constructions comme suit, bien que cela puisse réduire la lisibilité :

Code :

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

1
2
 
BaseAliment *c= new  DecorateurGout( *(new Aliment(1.5,"Gauffre")),0.2,"Sucre") ;

Mais je suis chagriné par le 2e new (new Aliment). Il a été alloué dynamiquement, mais ayant aucune référence sur le pointeur, comment peut-on le détruire?

[nuKs]

Pour le détruire, trois solutions:

• Gérer la mémoire dans les Décorateurs.
• Utiliser un smart pointer.
• Utiliser un ramasseur de miette.

En réalité, je pense (sans aucune certitude), que la mémoire doit être gérée dans les Décorateurs. En effet, une même variable pointe sur un nouvel objet à chaque ajout de décorateur. Le dernier objet créé (un décorateur en principe) se doit de détruire l'objet le précédent pour assurer une certaine transparence dans la gestion de la mémoire.

En conclusion le constructeur de la classe Decorateur devrait se définir ainsi:

Code :

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

1
2
3
4
5
Decorateur::Decorateur(BaseAliment& base,double prix,const std::string& name):
BaseAliment(prix,name),m_base(base)
{
    delete base;
}

Mais ça reste risqué et celui qui utilise l'objet à plutôt intérêt à bien connaître son fonctionnement.
De mon côté, ce qui me rend septique sont les performances de ce patron ?

Edit: Mon exemple au dessus n'est pas valide, j'avais mal compris le fonctionnement et j'ai trop rapidement vus qu'il y avait utilisation d'un constructeur de copie au lieu d'une relation explicite par pointeur.

[Trunks]

J'ai oublié le lien : http://come-david.developpez.com/tut...=Decorateur#LV

En occurence, c'est aucun des 2 premières solutions.

La 1e, gérer ça par la classe elle-même, je ne vois pas comment (comment savoir si l'objet fourni en paramètre a été construit statiquement ou dynamiquement?). Puis dans l'exemple, il y a aucun delete d'ailleurs.

La 2e solution non plus, vu qu'il s'agit d'un pointeur classique.

Je ne connais pas le ramasse-miette, mais je ne pense pas non plus en occurence ...

[white_tentacle]

Je confirme, le code d'exemple fuit sa mémoire comme ça ne devrait pas être permis (j'ai envie de dire que c'est une adaptation trop rapide d'un code java ou c#).

Après, je ne connais pas ce pattern, donc je ne sais pas qui est censé géré la durée de vie des objets.

[Alp]

L'objectif de ce tutoriel était clairement de faire découvrir les DPs avec application en C++, l'accent a donc plus été mis sur l'aspect conception que sur la justesse du code C++.

Toutefois, l'auteur prendra vos remarques en compte afin de faire une mise à jour, sans problème.

En n'oubliant pas que les DPs, particulièrement en C++ grâce à la généricité, doivent être réutilisables, que proposeriez-vous pour régler le soucis ?

[white_tentacle]

À mon avis, il faut gérer la durée de vie des objets dans le décorateur (et donc, stocker un pointeur plutôt qu'une reférence, et deleter m_base dans le destructeur de Decorateur). Je ne vois pas trop comment on peut s'en sortir autrement sinon.

Ensuite, soit :
- spécifier que l'objet BaseAliment doit avoir été alloué avec ::new
- fournir une méthode statique Create(...) dans chacune des classes, et des constructeurs protégés (mieux)

[3DArchi]

Si je comprend bien le pattern, il s'agit d'une composition. Donc, Decorateur devrait avoir un pointeur intelligent sur m_base; non?