Intérêt d'une factory versus un new

Bonjour,

Je suis en train d'étudier l'utilisation des dessign patterns ...

J'ai une question par rapport aux factories.

En fait je voudrais savoir les avantages et les inconvenients d'utiliser des factories, pourquoi utiliser une factory à la place d'un simple "new" d'une classe, dans quels cas les utiliser ...

Merci !!

La factory, c'est un new virtuel.
Avec une factory, pas besoin de connaître la classe, il suffit d'avoir un pointeur vers ladite factory...

Citation:

---

Envoyé par Médinoc

La factory, c'est un new virtuel.
Avec une factory, pas besoin de connaître la classe, il suffit d'avoir un pointeur vers ladite factory...

---

Exactement. Si ton code est écrit pour une interface (la fabrique, classe abstraite), il fonctionnera pour toute nouvelle classe qui dérive de celle ci par polymorphisme.
Lorsque ton code utilise plein de classes concrètes, tu devras modifier ce code à chaque ajout de nouvelles classes concrètes. Ce qui ne respecte pas le principe "ouvert - fermé".
En fournissant un pointeur vers une fabrique, tu te gardes bien d'instancier directement une classe abstraite.

-> cf http://come-david.developpez.com/tut...?page=sommaire

Il y a aussi d'autres avantages secondaires: une fonction factory peut changer de type de produit ou initialiser le produit différemment en fonction, par exemple, d'une option de la ligne de commande ou d'une valeur de configuration. Elle peut également accumuler des statistiques sur les créations d'objet, etc..

Carl

Merci de vos reponses qui m'ont éclairé assez .

Maintenant je me pose une question ...

Comment ça se passe au niveau de la destruction des objets générés par une factory ? C'est au client de la factory de les desallouer ou bien la destruction est encapsullée ?

Dans l'exemple du tutoriel des factories de developpez.com (http://come-david.developpez.com/tut...Fabrique#LIV-2)... il ne faudrait pas desallouer quelque part les objects qui sont crées ?

Généralement la factory est une source de données, et le client obtient la responsabilité de déclencher la libération.
Toutefois si la factory renvoie un handle/pointeur intelligent plutôt qu'un pointeur, alors la libération peut être implicite (et déterministe)

Je sais que des boost::XXX_ptr voire sdt::auto_ptr serait mieux en terme de gestion de mémoire.Mais les premier impose d'utiliser boost et les 2eme sont assez fourbe quand on les passe à une fonction.
D'où mon choix d'utiliser des pointeurs en dur.

donkeyquote : Sinon rien n'empeche la factory de garder une trace des objet qu'elle à créée, puis de les détruire sur demande.
Mais pour moi, une factory créer des objets, elle ne gère pas leur cycle de vie.

Citation:

---

Envoyé par Davidbrcz

Je sais que des boost::XXX_ptr voire sdt::auto_ptr serait mieux en terme de gestion de mémoire.Mais les premier impose d'utiliser boost et les 2eme sont assez fourbe quand on les passe à une fonction.

---

Si tu utilises un compilateur assez récent, implémentant TR1, shared_ptr et consorts sont inclus de base avec.

Hum, je savais que TR1 était incluse par un certain nombre de compilos, mais je pense ce n'est pas encore assez répandu.
Pour moi, pas de problème (g++ 4.2.3) mais est ce le cas de VC++ 6.0 qui est malheureusement encore assez utilisé et même des versions supérieures de VC.

La seule fourberie de std::auto_ptr que je connaisse, c'est de l'utiliser comme membre avec un destructeur inline.

tu as déjà passé un std::auto_ptr à une fonction ?

À une fonction puit. Oui.
C'est même un artéfact très parlant sur le plan sémantique. Bien plus qu'une fonction qui prend un pointeur et dont il faut regarder le code pour savoir ce qu'elle en fait.

Pour ceux qui ne savent pas ou ont oublié, on a ça dans la FAQ C++ : http://cpp.developpez.com/faq/cpp/?p...NTEURS_autoptr

D'où en effet, comme l'a dit Luc, il faut savoir si la fonction sait qu'elle devient propriétaire selon le type de passage en argument, et dans ce cas si elle agit correctement, ne laissant aucune erreur se profiler.

A partir du moment où l'on sait que le concept de l'auto_ptr est basé sur la propriété du pointeur et que les copies/assignations ont pour effet le transfer de propriété, on est pas surprit.

J'avais lu ça, je ne connaissait pas l'équivalent français, fonction puit :

Citation:

---

The transfer of ownership implies a special use for auto_ptrs; that is, functions can use them to transfer ownership to other functions. This can occur in two different ways:

• A function can behave as a sink of data. This happens if an auto_ptr is passed as an argument to the function by value. In this case, the parameter of the called function gets ownership of the auto_ptr. Thus, if the function does not transfer it again, the object gets deleted on function exit:

Code:

---

void sink(std::auto_ptr<ClassA>); //sink() gets ownership

---

• A function can behave as a source of data. When an auto_ptr is returned, ownership of the returned value gets transferred to the calling function. The following example shows this technique:

Code:

---

1 2 3 4 5 6

std::auto_ptr<ClassA> f() { std:: auto_ptr<ClassA> ptr(new ClassA); //ptr owns the new object ... return ptr; //transfer ownership to calling function }

---

---

A noter que l'on peut empêcher le transfer de propriété des auto_ptr en les déclarant const. Cela n'interdit pas d'accéder en lecture écriture à la donnée pointée.

Dans XC++ de Sutter, donc dans GOTW, il y a un item sur std::auto_ptr, et ça cause de puits/sources si mes souvenirs sont bons, si ça t'intéresse.

EDIT : c'est http://gotw.ca/gotw/025.htm

Citation:

---

Envoyé par NiamorH

J'avais lu ça, je ne connaissait pas l'équivalent français, fonction puit :

---

Je ne saurais garantir que c'est LE équivalent français. C'est la traduction qui me parait la plus naturelle, bien que sink ait un sens légèrement différent.

Citation:

---

Envoyé par Alp

Dans XC++ de Sutter, donc dans GOTW, il y a un item sur std::auto_ptr, et ça cause de puits/sources si mes souvenirs sont bons, si ça t'intéresse.

EDIT : c'est http://gotw.ca/gotw/025.htm

---

carrément merci ;)

Citation:

---

Envoyé par NiamorH

La seule fourberie de std::auto_ptr que je connaisse, c'est de l'utiliser comme membre avec un destructeur inline.

---

Précisons que le problème, ou plutôt la condition à l'usage de auto_ptr<T> est que le type T doit être complet pour instancier le destructeur auto_ptr<T>::~auto_ptr(), ce qui limite l'usage d'auto_ptr pour implémenter un pimpl :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

X.hpp : class X { class impl; // type incomplet selon le principe du pimpl std::auto_ptr<impl> pimpl; public: ~X () {} // ici, instancie auto_ptr<impl>::~auto_ptr () // erreur : // impl est incomplet ici, delete d'un impl* indéfini };

---

alternative qui n'est pas mieux :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

X2.hpp : class X2 { class impl; std::auto_ptr<impl> pimpl; public: // ~X2 () déclaré implicitement (ok) }; toto.cpp : #include "X2.hpp" X2 x; // ~X2 () est est défini implicitement ici, erreur : // instancie auto_ptr<X2::impl>::~auto_ptr () // X2::impl est incomplet ici, delete d'un X2::impl* indéfini

---

la solution :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

X3.hpp : class X3 { class impl; std::auto_ptr<impl> pimpl; public: ~X3 (); }; X3.cpp : #include "X3.hpp" class X3::impl { // selon le principe du pimpl, on définit ici le mécanisme interne de X3 ... }; X3::~X3 () {} // instancie auto_ptr<X3::impl>::~auto_ptr () // ok: X3::impl est complet ici

---