Discussion :

[dhoorens]

Bonjour à tous,

J'ai les classes suivantes:

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
 
class Base{
virtual void f();
};
 
class A: public Base{
void f();
};
 
class B: pulbic Base{
void f();
};
 
class C: public Base{
void f();
};

je cherche à écrire une fonction du type

Code :

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

1
2
3
4
5
6
 
Base*  mafonction (Base* ptrBase){
if (typeid(ptrBase) == typeid(A)) return (new A);
else if (typeid(ptrBase) == typeid(B)) return (new B);
else if (typeid(ptrBase) == typeid(C)) return (new C);
}

du moins de manière plus élégante et en ne devant pas rajouter une ligne supplémemtaire chaque fois que je rajouterai un objet dérivé de la classe Base...

Si la question est claire, est ce que qqun sait m'aider?
Merci beaucoup
D

[BainE]

Bonjour,

tu cherches a créer une factory (cf pattern factory), je crois pas que ce que tu souhaite soit possible (ca se fait en Java et C# par reflexivité, mais la; peut etre Qt avec moc...).

De ce que je connais de ce pattern je pense que t es obligé de faire comme tu fais.

Mais peut etre qu un coup de google sue le pattern factory t en dira plus

[dhoorens]

woauw ca a l'air un brin compliqué ce bazar...
Ya pas des trucs plus simples.?

[dhoorens]

Qt avec moc...

ç-à-d?

[BainE]

moc c'est un préprocesseur (heu en tout cas pour ce post on va faire comme si) fournit par le framework Qt (librairie graphique, de thread, XML...).
Il me semble me souvenir qu on pouvait faire de la reflexivité (en fait ca consiste a lire le code source et invoquer des méthode dynamiquement, par leur nom en string par exemple).

Sinon le pattern (un pattern est une "conception standardisé" pour un probleme donné) factory est pas compliqué du tout, c'est le plus simple (avec singleton).
En fait tu le fais deja sans le savoir.

[Mat007]

Salut,

Pourquoi pas quelque chose comme :

Code :

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

1
2
3
4
5
6
7
class Base {
  virtual Base* clone() = 0;
};
 
class A: public Base {
  virtual Base* clone() { return new A(); }
};

?

Si c'est pas un vrai clone tu peux l'appeler instanciate, create, ...

MAT.

[dhoorens]

Mais si maintenant je rajoute une classe D qui dérive aussi de Base, je suis obligé de rajouter dans la définition de D la solution que tu me proposes...?

Si c'est le cas, je voudrais l'éviter, car dans mon code, il a beaucoup de chance que je doive rajouter des classes assez souvent....

[Sylvain Togni]

Une solution alors serait de factoriser la fonction dans une classe template :

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
class Base
{
public:
  virtual Base* create() const = 0;
};
 
template<class T>
class Derived : public Base
{
public:
  virtual Base* create() const {return new T;}
};
 
class A : public Derived<A>
{
};
 
class B : public Derived<B>
{
};

[r0d]

J'aurais fait un peu différemment (un peu plus simple je crois):

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
template<class T>
class Base
{
public:
   virtual ~Base();
   static T* create() { return new T; }
   virtual void f() {}
};
 
class A : public Base<A>
{
public:
   void f();
};
 
class B : public Base<B>
{
public:
   void f();
};

Qui s'utilise ainsi:

Code :

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

1
2
A* pA = Base<A>::create();
B* pB = Base<B>::create();

Mais au final, ce n'est rien de plus qu'un pattern factory "templaté".


edit: rajouté l'héritage avec, comme exemple, la fonction f()

[Sylvain Togni]

La différence, quand même, c'est qu'on perd le polymorphisme dynamique (A et B ne dérivent plus de la même classe).

[dhoorens]

La différence, quand même, c'est qu'on perd le polymorphisme dynamique (A et B ne dérivent plus de la même classe).

CE que je ne veux pas perdre... :-/

[r0d]

La différence, quand même, c'est qu'on perd le polymorphisme dynamique (A et B ne dérivent plus de la même classe).

En un sens oui. Mais concrètement, qu'y perdons-nous?

En fait, je pense que concrètement ça va dépendre du contexte. D'un point de vue "conceptuel", ma proposition n'est pas belle, car je fusionne la factory et l'interface, mais dans la pratique, si l'interface n'a pas vocation à être plus qu'une interface et que celle-ci reste simple, je pense que ça reste une bonne solution. Je reste un adepte du rasoir d'Ockham.