Discussion :

[Steph_ng8]

Bonjour,
J'imagine qu'il y a d�j� (eu) un � d�bat � sur ce sujet, mais je ne sais pas exactement o� chercher...

Bref, pour le cas o� l'intitul� ne serait pas assez explicite, j'aimerais savoir quelle est la meilleure fa�on (selon vous) d'�crire une classe dont plusieurs constructeurs partagent un bout de code :

1. avec une classe-m�re dont le seul but est de factoriser ce bout de code dans son propre constructeur ;
2. �crire une fonction sp�cifique pour ce bout ce code.

Au cas o� je ne serais toujours pas clair, je me retrouve dans cette situation :

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
class uneClasse
{
 
    public:
        uneClasse(...) { // Un constructeur
             // Code partagé
             ...
 
             // Code spécifique
             ...
        }
 
        uneClasse(...) { // Un autre constructeur
             // Code partagé
             ...
 
             // Code spécifique
             ...
        }
 
        ...
 
};

Quelle la meilleure solution pour factoriser le code partag� ?

Cas 1 :

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
32
class _base
{
 
    protected:
        _base(/* paramètres éventuels */) {
            // Code partagé
            ...
        }
 
        ~_base() {
            // Éventuellement du code
        }
 
};
 
class uneClasse : private _base
{
 
    public:
        uneClasse(...) : _base(...) { // Un constructeur
             // Code spécifique
             ...
        }
 
        uneClasse(...) : _base(...) { // Un autre constructeur
             // Code spécifique
             ...
        }
 
        ...
 
};

Cas 2:

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
class uneClasse
{
 
    private:
        void init(/* paramètres éventuels */) {
            // Code partagé
            ...
        }
 
    public:
        uneClasse(...) { // Un constructeur
             init(...);
             // Code spécifique
             ...
        }
 
        uneClasse(...) { // Un autre constructeur
             init(...);
             // Code spécifique
             ...
        }
 
        ...
 
};

Merci !

[Astraya]

Bonjour ,

Cas 1

[Mat007]

Salut,

Aucun en ce qui me concerne, et je ne me souviens pas la derni�re fois que j'ai senti le besoin de factoriser.
En g�n�ral je trouve que c'est un code smell d'une classe trop grosse...

MAT.

[koala01]

Salut,

Le deuxi�me cas, sans h�sitation...

Il n'y a aucune raison pour cr�er une classe de base si tu n'en a pas besoin pour autre chose.

N'oublie pas le fameux KISS (Keep It Simple, Stupid)

Ce que tu peux faire, sous r�serve, c'est factoriser le code identique dans une fonction priv�e:

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 UneClasse
{
    public:
        UneClass()
        {
            subinit(/* arguments éventuels*/);
            /* le reste */
        }
        UneClass(/* les arguments qui vont bien */)
        {
             subinit(/*arguments éventuels */);
             /* le reste */
        }
    private:
        subinit(/* arguments éventuels */)
        {
             /* ce qui doit être fait */
        }
};

Mais attention !!! La grosse r�serve tient dans l'�ventualit� o� "subinit" serait une fonction virtuelle et ou UneClasse servirait de base � d'autres classes.

En effet, ce serait le code relatif � UneClasse::subinit qui serait appel�, et non le code relatif � la red�finition de cette fonction dans les classes d�riv�es, �tant donn� que, au moment o� le constructeur de la classe de base est appel�, les classes d�riv�es ne sont pas encore construites

[Steph_ng8]

Salut,

Aucun en ce qui me concerne, et je ne me souviens pas la derni�re fois que j'ai senti le besoin de factoriser.
En g�n�ral je trouve que c'est un code smell d'une classe trop grosse...

MAT.

Ah oui tiens, je n'ai pas pens� � cette option dans le sondage...
Quelqu'un sait comment on peut le modifier ?

[Steph_ng8]

Salut,

Le premier cas, sans h�sitation...

Il n'y a aucune raison pour cr�er une classe de base si tu n'en a pas besoin pour autre chose.

Bah le cas 1, c'est justement cr�er une classe de base...

Ce que tu peux faire, sous r�serve, c'est factoriser le code identique dans une fonction priv�e:

�a, c'est le cas 2...
C'est moi o� il y a une probl�me de compr�hension quelque part ?

Mais attention !!! La grosse r�serve tient dans l'�ventualit� o� "subinit" serait une fonction virtuelle et ou UneClasse servirait de base � d'autres classes.

En effet, ce serait le code relatif � UneClasse::subinit qui serait appel�, et non le code relatif � la red�finition de cette fonction dans les classes d�riv�es, �tant donn� que, au moment o� le constructeur de la classe de base est appel�, les classes d�riv�es ne sont pas encore construites

Ah non, dans la mani�re dont je vois les choses, cette fonction d'initialisation n'a aucune raison d'�tre virtuelle.
D'ailleurs, elle ne devrait �tre appel�e que pour la cr�ation de la couche � uneClasse �.

[Steph_ng8]

Sinon, juste histoire d'�tre s�r, �tant donn� que � subinit � est priv�e, m�me si des classes filles d�finissent une fonction du m�me nom et pour le m�me usage, il n'y a pas de risque de conflit ?

[koala01]

Bah le cas 1, c'est justement cr�er une classe de base...


�a, c'est le cas 2...
C'est moi o� il y a une probl�me de compr�hension quelque part ?

Ouppsss... c'est moi qui ai invers� les deux cas, je corrige mon intervention

Ah non, dans la mani�re dont je vois les choses, cette fonction d'initialisation n'a aucune raison d'�tre virtuelle.
D'ailleurs, elle ne devrait �tre appel�e que pour la cr�ation de la couche � uneClasse �.

Nous sommes bien d'accord l� dessus

[JolyLoic]

Ah oui tiens, je n'ai pas pens� � cette option dans le sondage...
Quelqu'un sait comment on peut le modifier ?

Je viens de le modifier pour toi... Fais moi signe si tu n'aimes pas l'intitul� choisi.

Sachant que j'ai un autre probl�me avec ta question de d�part : Souvent, le corps de mes constructeurs est vide, et c'est la liste d'initialisation qui contient tout...

[Davidbrcz]

Perso j'attends C++0X et la d�l�gation des constructeurs. Sinon, si j'ai d�j� une classe de base, j'essaye de factoriser dans la classe de base, sinon j'essaye de voir pourquoi j'ai besoin de diff�rents constructeurs et si je ne peux pas en �liminer (en utilisant des valeurs par d�fauts ....).

[hiura]

Perso j'attends C++0X et la d�l�gation des constructeurs.

Serait-ce un syst�me semblable � celui de Java ?

(Pour ceux qui ne connaisse pas : )

Code :

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

1
2
3
4
5
6
7
 
class B {
public B() {
  this("abc", 42); // Appel l'autre Ctor.
}
public B(String s, int i) {
  :

[Davidbrcz]

Serait-ce un syst�me semblable � celui de Java ?

Regarde par toi m�me ><

http://www2.research.att.com/~bs/C++...elegating-ctor

[Steph_ng8]

Ah oui tiens, je n'ai pas pens� � cette option dans le sondage...
Quelqu'un sait comment on peut le modifier ?

Je viens de le modifier pour toi...

Ah, merci JolyLoic, c'est sympa.

Fais moi signe si tu n'aimes pas l'intitul� choisi.

� Ce genre de besoins semble louche � ?!?!
Hum, si tu veux...

[Steph_ng8]

Sachant que j'ai un autre probl�me avec ta question de d�part : Souvent, le corps de mes constructeurs est vide, et c'est la liste d'initialisation qui contient tout...

Sinon, si j'ai d�j� une classe de base, j'essaye de factoriser dans la classe de base, sinon j'essaye de voir pourquoi j'ai besoin de diff�rents constructeurs et si je ne peux pas en �liminer (en utilisant des valeurs par d�fauts ....).

Alors je n'ai peut-�tre pas �t� assez clair, mais je pars du principe que le code a d�j� �t� factoris� au maximum.
Autrement dit, tout ce qui peut �tre remont� dans les �ventuelles classes-m�re l'a �t� (� condition qu'elles soient accessibles), les param�tres par d�faut sont utilis�s au maximum pour r�duire le nombre de constructeurs (quand cela est justifi�), et tout ce qui peut �tre fait dans la liste d'initialisation ne l'est pas fait ailleurs.
Et malgr� tout �a, il reste des bouts de code communs.

Ce n'est semble-t-il pas une situation que l'on rencontre souvent, mais une fois suffit pour se poser la question...

Bon, je crois qu'un cas pratique s'impose...
Imaginez que vous ayez deux constructeurs, l'un prenant un std::string comme param�tre et l'autre un char*.
Je vous entends hurler d'ici : � Vire le constructeur avec le char*, il y a la conversion implicite char* -> std::string. �
Fort bien, mais si par la suite on a besoin de travailler avec un char* (pour ouvrir un fichier, par exemple), pas s�r que ce soit le plus efficace d'allouer un std::string pour finalement aller rechercher les � donn�es brutes �, autant utiliser tout de suite le char*.

Et pourquoi ne pas faire comme la STL et ne faire qu'un constructeur prenant un char* comme param�tre ?
Pour simplifier la vie des gens qui vont utiliser ma classe (moi y compris), qu'ils puissent utiliser sans se poser de question un std:;string ou un char*.

Sinon, j'ai eu ce probl�me quand je faisais des fen�tres en Qt.
Je ne vais pas m'amuser � r��crire le code qui remplit la fen�tre dans tous les constructeurs que je ne peux pas fusionner, je ne peux pas le faire via la liste d'initialisation, et impossible de le faire remonter dans une classe-m�re.

Voil�...
�a vous para�t absurde comme motivation ?

[koala01]

En fait, d'exp�rience, il y a peu de cas dans lesquels il serait int�ressant de convertir une std::string en const char * au niveau du constructeur:

Si c'est pour convertir la std::string en "autre chose" (par exemple en valeurs(s) num�rique(s)), l'id�al sera quand m�me de passer par... un std::stringstream.

Si c'est pour manipuler un fichier, par exemple, l'id�al restera de n'ouvrir le fichier que "en cas de besoins" et de le garder "aussi peu" ouvert que possible, pour ne pas emp�cher l'acc�s � ce fichier par ailleurs (et surtout par d'autres applications qui pourraient tourner en m�me temps que la tienne).

Il me semble m�me �tait question de voir de quelle mani�re supprimer les const char*de l'ensemble des fonctions et des classes qui les utilisent comme argument, mais je crois que, pour l'instant, le gros de l'effort porte sur la cr�ation de la liste exhaustive de celles-ci, et que cela pourrait provoquer certains probl�mes de r�tro compatibilit� (� cause de l'op�rateur de conversion implicite de const char * en std::string)

Quoi qu'il en soit, il me semble r�ellement pr�f�rable d'effectivement convertir les chaines "C style" "chaque fois que faire se peut" et de les maintenir, au sein de tes classes perso, sous la forme de std::string

Par contre, il reste vrai que certaines parties du constructeur peuvent malgr� tout �tre factoris�es une fois que tu as cr�� correctement tes listes d'initialisation: les contr�les de coh�rence �ventuels, par exemple, mais toujours en �tant bien d'accord sur le fait que les fonctions factoris�es ne doivent �tre effectu�es que dans le cadre du type pr�cis dont il est question, et en restant conscient du fait que cela *peut* poser des probl�mes lors de l'h�ritage

[Klaim]

Perso j'attends C++0X et la d�l�gation des constructeurs.

Aussi surprenant que cela paraisse, cette feature serait visiblement r��xamin�e pour un potentiel retrait du standard : http://www.informit.com/guides/conte...lus&seqNum=504


Je ne sais pas clairement quels problemes la feature peut apporter, mais en tout cas je sais que �a serait sacr�ment dommage de ne pas l'avoir.

Contrairement � l'auteur de l'article, pour moi les valeurs d'initialization par d�faut (dans la d�claration de classe) sont fondamentalement diff�rents d'un constructeur commun. Ne serait-ce que parceque l'un des deux n'est pas du code execut�.

[Steph_ng8]

Ce que je pensais ce confirme, � savoir qu'il vaut mieux �crire une fonction d'initialisation.

Merci � tous ceux et celles qui ont vot� et/ou r�pondu !

[Mat007]

En fait il y a une autre possibilit�, que pour le coup j'utilise tr�s souvent.

Dans le fichier d'ent�te :

Code :

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

1
2
3
4
5
6
7
8
9
class uneClasse
{
 
    public:
        uneClasse(...); // Un constructeur
        uneClasse(...); // Un autre constructeur
    private:
        Bam bam_;
};

Et dans le fichier d'impl�mentation :

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
 
namespace
{
    Bam make_bam(...)
    {
        ......
        return bam;
    }
}
 
uneClasse::uneClasse( ... ) // un constructeur
 : bam_( make_bam( ... ) )
...
{}
 
uneClasse::uneClasse( ... )
 : bam_( make_bam( ... ) ) // un autre constructeur
...
{}

Donc avec des fonctions locales pour factoriser les cr�ations/configurations de membres.

MAT.

[Steph_ng8]

Je vois...

Mais c'est vraiment n�cessaire d'utiliser un attribut membre ?

[koala01]

Je vois...

Mais c'est vraiment n�cessaire d'utiliser un attribut membre ?

H� bien, tout d�pend de ce que tu veux factoriser, mais, de mani�re g�n�rale, il y a trois choses que tu risques de factoriser:

1. La v�rification des pr� conditions
2. La v�rification des post conditions
3. l'initialisation de membres, sur base de valeurs qui ne sont pas forc�ment du type du membre.

L'exemple que donne Mat est le troisi�me de la liste

Pour te donner un exemple concret des possibilit�s, imagine que tu cr�es une application"multi document", pour laquelle on peut cr�er un document sans lui donner de nom.

Le nom donn� par d�faut serait sans doute "Unnammed_XXX", et tu aura sans doute un gestionnaire de document (qui maintient l'ensemble des documents ouverts) qui ressemblera peu ou prou � quelque chose comme

Code :

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

1
2
3
4
5
6
7
8
9
10
class DocumentManager
{
    public:
        /* je passe les typdefs et les fonctions qui ne nous intéressent pas
         * ici
         */
        size_t count() const{return items_.size();}
    private : 
        LaCollection items_;
};

Ta classe document ressemblerait sans doute �

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
class Document
{
    public:
        /* le construteur créant un document anonyme */
        Document();
        /* et celui créant un document dont le nom est déjà connu */
        Document(std::string const & );
        /* sans oublier... l'accesseur sur le nom */
        std::string const & name() const{return name_;}
        /* et toutes les fonctions que je ne montre pas ici */
    private:
        std::string name_;
};

L'impl�mentation du constructeur par d�faut ressemblerait donc � quelque chose comme

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
#include <document.hpp>
#include <documentmanager.hpp>
#include <sstream>
namespace
{
    void preConditions()
    {
         // les assertions qui vont bien avec les pré conditions 
    }
    std::string const doName()
    {
        preConditions();
        std::stringstream ss;
        ss<<"Unnamed_"<<DocumentManager::instance().count();
        return ss.str();
    }
    void postConditions()
    {
         if(il_y_a_eu_un_probleme)
             trhow LexceptionQuiVaBien();
    }
}
Document::Document():name_(doName())
{
    postConditions();
}
Document::Document(std::string const & n):name_(n)
{
    postConditions();
}