Discussion :

[donkeyquote]

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 !!

[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...

[poukill]

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

[Invité]

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

[donkeyquote]

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 ?

[Luc Hermitte]

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)

[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.
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.

[JolyLoic]

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.

[Davidbrcz]

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.

[NiamorH]

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

[Davidbrcz]

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

[Luc Hermitte]

À 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.

[Alp]

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.

[NiamorH]

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 :

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 :

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

   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 :

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

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.

[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

[Luc Hermitte]

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.

[NiamorH]

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

[corrector]

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 :

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

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 :

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

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 :

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

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