Discussion :

[Invit�]

Bonsoir,

Il y a quelque chose que je ne saisis pas compl�tement. J'essaie de comprendre ce pattern mais rien n'y fait ..

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
23
24
25
26
27
28
29
30
31
class Createur
{
    public :
    virtual std::string getMarque() const=0;
    friend std::ostream &operator<<(std::ostream &o,const Createur *v)
    {
        return o << v->getMarque();
    }
    static Createur *createVoiture(std::string o);
};
        
        
        class CreateurConcretRenault : public Createur {
        public:
            std::string getMarque() const { return "Renault"; }
        };
        
        class CreateurConcretFiat : public Createur {
        public:
            std::string getMarque() const { return "Fiat"; }
        };

void f(const Createur *v)
        { std::cout << "Voiture " << v << std::endl; }
        
        Createur *Createur::createVoiture(std::string o)
        {
            if(o=="fr") return new CreateurConcretRenault();
            if(o=="it") return new CreateurConcretFiat();
            return 0;
        }

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
    int main()
    {
        Createur *v=Createur::createVoiture("it");
        f(v);
    
    return 0;}

1) En quoi dans ce code peut-on dire que la m�thode createVoiture est une m�thode de Fabrication ?
Serait-ce parce que on ne cr�er pas directement l'objet � partir d'un new mais � partir d'une m�thode qui s'occupe de cela ?

2)Son utilis�, c'est donc pour �tre " plus efficace " ?

3)D'ailleurs dans le main , si on regarde bien , on ne voit plus le type concret ( on ne fait pas de new concret , du genre newRenaut,newFiat ) , serait-ce la raison ? Faire en sorte que le type concret n'apparait pas dans le main ?

4) Derniere question : J'ai vu que certains disaient que les m�thodes statiques n'�taient pas un bon choix , et qu'il pr�f�rait cr�er un objet puis appliquer la m�thode � cette instance. Mais comment faire cela sachant qu'on ne peut pas instancier une classe abstraite en c++ ?

[pseudocode]

D'ailleurs dans le main , si on regarde bien , on ne voit plus le type concret ( on ne fait pas de new concret , du genre newRenaut,newFiat ) , serait-ce la raison ? Faire en sorte que le type concret n'apparait pas dans le main ?

Oui, c'est cela. Ce pattern permet de d�coupler l'interface (type abstrait) et l'impl�mentation (type concret) d'un objet. La fabrique s'occupe de cr�er une instance "concr�te" et de la renvoyer sous forme d'interface.

Dans ton cas, c'est m�me un pattern "Abstract Factory" car tu as aussi d�coupl� l'interface et l'impl�mentation de la fabrique. Au final, ta fonction main() ne connait que l'interface de la fabrique et l'interface de l'objet.

[Invit�]

Merci de ta r�ponse , �a m'aide beaucoup sachant que ce n'est pas toujours clair sur le net .

Par contre je sais pas si tu as vu mon �dit, tu pourrais m'�clairer sur ma quatri�me question ( et aussi sur la raison de faire cela ? ) ?

Du coup , tu dis que dans l'Abstract factory , on ne voit que l'interface et la fabrique de cette interface.
Que voit-on alors dans une Factory Method ?

[pseudocode]

Merci de ta r�ponse , �a m'aide beaucoup sachant que ce n'est pas toujours clair sur le net .

Par contre je sais pas si tu as vu mon �dit, tu pourrais m'�clairer sur ma quatri�me question ( et aussi sur la raison de faire cela ? ) ?

Si on utilise une m�thode non-statique, il faut forc�ment instancier la classe de la fabrique. Donc on se retrouve coupl� avec la classe concr�te de la fabrique.

Si on veut absolument conserver le d�couplage de l'abstract factory, il faudrait instancier cette factory "avant", et passer son interface en argument de la fonction main().

Du coup , tu dis que dans l'Abstract factory , on ne voit que l'interface et la fabrique de cette interface.
Que voit-on alors dans une Factory Method ?

une Factory Method ce n'est pas un vrai pattern de conception. C'est une m�thode qui cr�e une instance de classe et renvoie son interface.

C'est du d�couplage de "code", mais pas du d�couplage de "conception".

[Invit�]

Raa je sais que je suis dur mais je n'ai toujours pas certaines r�ponses qui me bloque ..

1) Quand tu dis que c'est une Abstract Factory du fait que j'ai d�coupl� l'interface et l'impl�mentation de la fabrique , c'est parce qu'on sait seulement que avec

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

Createur *v=Createur::createVoiture("it");

cela retourne un objet dont on ne connait pas le type concret mais l'on connait seulement son interface ?

Du coup , qu'est ce qu'il y aurait de plus pour qu'elle ne soit plus Abstract mais Factory tout court ?

2) L'utilit� final tu dis est d'impl�menter l'interface et l'impl�mentation. Mais je ne vois toujours pas l'utilis� ? A quoi bon ?

[pseudocode]

Raa je sais que je suis dur mais je n'ai toujours pas certaines r�ponses qui me bloque ..

1) Quand tu dis que c'est une Abstract Factory du fait que j'ai d�coupl� l'interface et l'impl�mentation de la fabrique , c'est parce qu'on sait seulement que avec

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

Createur *v=Createur::createVoiture("it");

cela retourne un objet dont on ne connait pas le type concret mais l'on connait seulement son interface ?

Du coup , qu'est ce qu'il y aurait de plus pour qu'elle ne soit plus Abstract mais Factory tout court ?

hum... je vais essayer de simplifier ton exemple, car tes noms de classe sont un peu ambigus.

Code C++ :

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
main() {
  /* couplage interface / Implémentation */
  Voiture *v = new RenaultMegane();
  f(v);
}
 
main() {
  /* factory */
  Renault *renault = new Renault();
  Voiture *v = renault->createMegane();
  f(v);
}
 
main() {
  /* abstract factory */
  Constructeur *constructeur = new Renault();
  Voiture *v = constructeur->createVoiture("Megane");
  f(v);
}

2) L'utilit� final tu dis est d'impl�menter l'interface et l'impl�mentation. Mais je ne vois toujours pas l'utilis� ? A quoi bon ?

En reprenant mon exemple, ca permet de facilement cr�er de nouvelles classes concr�tes sans trop impacter le code existant.

Code C++ :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
main() {
  Constructeur *constructeur = new Mandataire("Renault", "Dacia", "Peugeot", "Citroen");
  Voiture *v = constructeur->createVoiture("Megane");
  f(v);
}

[Invit�]

Tu es d'accord avec moi concernant Abstract Factory que ( selon mon premier exemple ) :

-On veut pouvoir cr�er des objets de diff�rents types mais appartenant � une
m�me � famille �.
->C'est ce que l'on fait avec createVoiture qui elle , cr�e des objets de diff�rents types d'une m�me famille ( voitureA , voitureB .. )

-La cr�ation doit pouvoir se faire au travers d'une seule et m�me classe (une usine de meuble abstraite)

-Les objets peuvent �tre cr��s par diff�rentes classes (par exemple des usines des usines concr�tes) qui chacune peuvent produire plusieurs types d'objets de la famille
-> �a c'est par exemple classe Createur , puis sous classe Voiture1,Voiture2 , puis encore sous classe Voiture1_modeleA,voiture1_modeleB etc .. ?

Les objets doivent pouvoir �tre manipul�s sans que l'on ait besoin de savoir quelle classe (usine) les a cr��s
-> Hum ? C.A.D ?

[pseudocode]

Tu es d'accord avec moi concernant Abstract Factory que ( selon mon premier exemple ) :

-On veut pouvoir cr�er des objets de diff�rents types mais appartenant � une
m�me � famille �.
->C'est ce que l'on fait avec createVoiture qui elle , cr�e des objets de diff�rents types d'une m�me famille ( voitureA , voitureB .. )

Cette caract�ristique n'est pas obligatoire pour une fabrique. On peut avoir une fabrique qui instancie toujours la m�me classe concr�te, ou alors qui instancie des classes concr�tes diff�rentes.

-La cr�ation doit pouvoir se faire au travers d'une seule et m�me classe (une usine de meuble abstraite)

Oui. C'est la caract�ristique particuli�re d'une fabrique abstraite.

-Les objets peuvent �tre cr��s par diff�rentes classes (par exemple des usines des usines concr�tes) qui chacune peuvent produire plusieurs types d'objets de la famille
-> �a c'est par exemple classe Createur , puis sous classe Voiture1,Voiture2 , puis encore sous classe Voiture1_modeleA,voiture1_modeleB etc .. ?

Idem, cette caract�ristique n'est pas obligatoire pour une fabrique abstraite. Mais c'est tout de m�me l'int�ret d'utiliser ce pattern.

Les objets doivent pouvoir �tre manipul�s sans que l'on ait besoin de savoir quelle classe (usine) les a cr��s
-> Hum ? C.A.D ?

Oui. C'est la caract�ristique g�n�rale d'une fabrique: elle renvoie une interface de l'objet, et pas son type concret.

[Invit�]

Merci beaucoup, je comprends mieux tes exemples surtout la Abstract Factory qui elle ne montre que des interfaces.

Thanks you so much !