[debat] paramètres au construceur ou methode init?

Bonjour à tous,

j'ai créé un certain nombre de classe ces derniers temps, et à chaque fois que je créé une nouvelle classe, je me pose la question:
"est-ce que je met tout un tas de paramètres dans le constructeur ou est-ce que je ne fais qu'un constructeur par défaut et je créé une méthode d'initialisation pour ma classe?"

Exemple: je fais ça

Code:

---

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

classe MaClasse { public: MaClasse(int val1, int val2, string leNom);   private: int m_valeur1,m_valeur2; string m_leNom; }   MaClasse::MaClasse(int val1, int val2, string leNom) { m_valeur1 = val1; m_valeur2 = val2; m_leNom = leNom; }

---

ou ça?

Code:

---

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

classe MaClasse { public: MaClasse(); void init(int val1, int val2, string leNom);   private: int m_valeur1,m_valeur2; string m_leNom; }   MaClasse::MaClasse(){}   void MaClasse::init(int val1, int val2, string leNom) { m_valeur1 = val1; m_valeur2 = val2; m_leNom = leNom; }

---

Dans quel cas utiliser quelle méthode? Qu'en pensez-vous?

salut,

moi je ferais ça

Code:

---

1 2 3 4 5 6 7 8 9

... public: MaClasse(int val1, int val2, string leNom); ...   MaClasse::MaClasse(int val1 = 0, int val2 = 0, string leNom = "") : m_valeur1(val1), m_valeur2(val2), m_leNom(leNom) { };

---

je pense que c'est plus efficace, il n'y a qu'un appel au constructeur.
(pour les valeurs par défaut tu mets ce que tu veux bien sur)

je ne vois pas l'intérêt de ta méthode init() :
- le constructeur sert entre autre à initialiser les attributs;
- si tu veux modifier tes attributs après construction, crée des accesseurs.

enfin, il me semble que c'est comme ça que l'on fait...

Citation:

---

Envoyé par bigboomshakala

moi je ferais ça

Code:
...
public:
MaClasse(int val1, int val2, string leNom);
...

MaClasse::MaClasse(int val1 = 0, int val2 = 0, string leNom = "")
: m_valeur1(val1), m_valeur2(val2), m_leNom(leNom)
{
};

---

Dans ce cas, est-ce que je peux déclarer un tableau de MaClasse comme ça:

Code:

---

1 2 3 4 5

Classe UneAutreClasse { ... MaClasse monTableau[10]; };

---

?

oui bien sur, dans ce cas les attributs des objets MaClasse du tableau prennent leur valeur par défaut

i.e. m_valeur1 = 0, m_valeur2 = 0 et m_leNom = ""

car le constructeur appelé est MaClasse(0,0,"") étant donné que tu ne passes pas de paramètres

Ok, et bien en effet, il n'y a aucun intérêt à faire un init.

Merci.

Pour les problèmes de tableaux / constructeurs, ne pas oublier que std::vector permet d'avoir des tableaux de classes ne possédant pas de constructeur par défaut :wink:.

Ha!! J'ai trouvé un exemple où ça peut-être intéressant d'avoir un init():

J'ai deux classes MaClasse1 et MaClasse2. MaClasse2 est une agregation de MaClasse1, par exemple:

Code:

---

1 2 3 4 5 6 7

class MaClasse2 { ... MaClasse1 monTableau[10]; ... }

---

Dans mon programme, j'ai:

Code:

---

1 2 3 4 5 6 7

MaClasse1 *p1 = new MaClasse1(); MaClasse2 c1; //ici, le tableau c1.MonTableau est alloué for (int i=0; i<10; i++) { c1.MonTableau[i].init(<mes paramètres>); }

---

Dans ce cas, je ne peux pas mettre un new dans ma boucle! Qu'en pensez-vous?

Bonjour,

Dans ce cas, tu ne fais que remplir ton tableau avec des données, donc le nom de la fonction init n'est pas très bien choisi, à mon avis:
c'est un simple accesseur, donc un nom comme Setxxxx serait plus clair que init, qui pour moi implique des opérations autres que simplement mettre à jour des valeurs.

Citation:

---

Envoyé par r0d

Ok, et bien en effet, il n'y a aucun intérêt à faire un init.

Merci.

---

Moi j'en connais au moins un interêt. Si le code d'initialisation peut déclencher des exceptions.

En effet tu ne peux pas faire ca :

Code:

---

1 2 3 4 5 6 7 8 9

try { MaClasse obj(...); } catch(...) { // ... }

---

Parce'que alors ta variable obj n'a pour portée que le bloc try{} ce qui est embêtant.
Alors que :

Code:

---

1 2 3 4 5 6 7 8 9 10

MaClass obj; try { obj.init(...); } catch(...) { // ... }

---

Ca va mieux :) J'avais déjà posé la question ici et il s'avère qu'il n'y a pas de solution hormis celle-là.

A quoi sert ton objet si tu n'as pas pu l'initialiser à l'état désiré ?

Sinon, de façon tordue, il y a :

Code:

---

1 2 3 4 5 6 7

ObjS o; try { ObjS o2("toto"); o2.swap(o); // je ne sais plus si on peut faire ça en une ligne   o = ObjS("titi"); }....

---

Concernant les tableaux, Loulou24 a donné la solution

Code:

---

1 2 3 4 5 6 7 8 9 10

struct ObjI { ObjI(int); private: ObjI(); // constructeur par défaut interdit .... }; ... std::vector<ObjI> v; for (int i=0 ; i!=10 ; ++i) v.push_back( ObjI(i) );

---

Citation:

---

Envoyé par Luc Hermitte

A quoi sert ton objet si tu n'as pas pu l'initialiser à l'état désiré ?

---

A rien mais il faut pouvoir gérer le cas où ca ne marche pas. Dans le premier cas même si ca réussi il est détruit à la fin du bloc .. c'est embêtant.

Citation:

---

Envoyé par Luc Hermitte

Sinon, de façon tordue, il y a :

Code:

---

1 2 3 4 5 6 7

ObjS o; try { ObjS o2("toto"); o2.swap(o); // je ne sais plus si on peut faire ça en une ligne   o = ObjS("titi"); }....

---

---

Je préfère ma fonction init(), plus clair à mon avis.

Avec une construction normale, si ça foire, tu n'as pas d'objet créé et tu sors du bloc, sinon tu as un objet construit qui sera détruit à la fin du bloc.

Si l'objet ne sert à rien, pourquoi s'embéter à le vouloir ?

Citation:

---

Envoyé par Luc Hermitte

Avec une construction normale, si ça foire, tu n'as pas d'objet créé et tu sors du bloc, sinon tu as un objet construit qui sera détruit à la fin du bloc.

Si l'objet ne sert à rien, pourquoi s'embéter à le vouloir ?

---

Oui mais j'ai pas spécialement envie de faire tout mon code lié à mon objet créé dans le bloc try{ }

???

Autre question : es-tu sûr que tu traites l'erreur à l'endroit où elle doit l'être ? (la question cachée dans la question se résume à "profites-tu du RAII?")

Citation:

---

Envoyé par Luc Hermitte

???

---

Code:

---

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

try { maclass obj(...)   // je dois mettre tout le code qui utilise obj ici } catch(...) { // ... }   // alors que je préfère le mettre ici en fait

---

Citation:

---

Envoyé par Luc Hermitte

Autre question : es-tu sûr que tu traites l'erreur à l'endroit où elle doit l'être ? (la question cachée dans la question se résume à "profites-tu du RAII?")

---

En fait on peut comparer avec les std::fstream. En effet lors qu'ouvre un fichier je dois faire ensuite un is_open() pour être sûr que ca a marché, (ou un if( !mon_fichier ) c'est pas là la question).
Moi au lieu je préfère lever une exception si la construction échoue et la récupérer pour la traiter.

Enfin moi je la trouve bien moi la fonction init() dans ce cas précis.

Et c'est bête parce'que l'on a déjà eu ce débat mais visiblement victime du délestage :?

Ne serait-ce point celui-ci ? http://www.developpez.net/forums/viewtopic.php?t=220238

:wink:

Citation:

---

Envoyé par Loulou24

Ne serait-ce point celui-ci ? http://www.developpez.net/forums/viewtopic.php?t=220238

:wink:

---

Exact ! Je croiais avoir fait un poste à part entière et je ne cherchais donc que dans les titres de mes postes. Désolé :)

Donc oui c'était ce poste et la solution a été pour moi de faire une fonction init() et tout marche très bien :)

Citation:

---

Envoyé par Yabo

Code:

---

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

try { maclass obj(...)   // je dois mettre tout le code qui utilise obj ici } catch(...) { // ... }   // alors que je préfère le mettre ici en fait

---

---

Et cette préférence est-elle fondée sur quelque chose ?

Citation:

---

Envoyé par Yabo

Citation:

---

Envoyé par Luc Hermitte

Autre question : es-tu sûr que tu traites l'erreur à l'endroit où elle doit l'être ? (la question cachée dans la question se résume à "profites-tu du RAII?")

---

En fait on peut comparer avec les std::fstream. En effet lors qu'ouvre un fichier je dois faire ensuite un is_open() pour être sûr que ca a marché, (ou un if( !mon_fichier ) c'est pas là la question).
Moi au lieu je préfère lever une exception si la construction échoue et la récupérer pour la traiter.

---

Tu souhaite lever une exception, ok, pourquoi pas. Par contre, si tu as besoin de try/catch pour faire du ménage, alors là, je ne suis pas d'accord (et je rejoins Luc). Il a été montré que c'est impossible à gérer comme ça, et que le RAII est bien suppérieur. Pour moi, un try/catch ne doit apparaître que dans 4 situations :
- Quand on est capable de gérer l'erreur (affichage, redémarrage de l'appli...)
- Une fois par thread au plus haut niveau, pour les cas qu'on a pas géré, histoire d'essayer en désespoire de cause d'afficher un message à l'utilisateur
- Quand on sort du langage C++ (passage à du C, Fortran... qui ne supportent pas les exceptions)
- Quand on adapte une exception d'une bibliothèque pour en faire une exception d'un autre type (et donc avec un throw à la fin du catch).

Citation:

---

Envoyé par Yabo

Et c'est bête parce'que l'on a déjà eu ce débat mais visiblement victime du délestage :?

---

Mais j'étais pas là à l'époque, alors que maintenant, je peux jouer aussi... :coucou:

Citation:

---

Envoyé par JolyLoic

Citation:

---

Envoyé par Yabo

Code:

---

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

try { maclass obj(...)   // je dois mettre tout le code qui utilise obj ici } catch(...) { // ... }   // alors que je préfère le mettre ici en fait

---

---

Et cette préférence est-elle fondée sur quelque chose ?

---

Ne pas imbriquer le code encore et encore. Luc m'avait déjà proposé cette solution :

Citation:

---

Envoyé par Luc Hermitte

Hum... Difficile de répondre de manière générale.
Si ton constructeur échoue, de toutes façons tu vas remonter et tu ne pourras pas continuer ta fonction. Il est des cas où l'on ne veut englober que le constructeur il vrai. Mais ne peux-tu pas tout simplement étendre ton try jusqu'à la fin de la fonction ? Quitte à faire un catch spécialisé sur les erreurs de construction de A.

---

Mais évidemment avec la classe A c'est envisageable mais la réalité est plus complexe.
Je viens de relire le code que j'avais fait à l'époque. Bon donc en gros ce qu'il me fallait c'était un objet qui ne soit pas un pointeur, qui ait une très grande portée dans le programme (c'était une classe pour gérer les fichiers de log donc j'ai besoin de l'objet un peu partout (rassurez-vous j'ai pas fais de variables globales ;))), et dont la contruction puisse être dans un bloc try{} catch(){}.

En relisant mon code ce que j'ai fait :

une fonction init() privée suceptible de lever une exception
une fonction begin() qui a la tête :

Code:

---

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

void CLog::Begin(const char *FileName, bool Overwrite) { try { Init(FileName, Overwrite); } catch(CLogErr &err) { err.debug(); cerr << "Log level set to None" << endl; SetLevel(None); } }

---

Et mon constructeur :

Code:

---

1 2 3 4 5

CLog::CLog(const char *FileName, bool Overwrite) { Begin(FileName, Overwrite); }

---

Donc en fait j'ai fait une fonction d'init mais pas dans le sens que j'ai évoqué précédemment. Ca date de juillet quand même ce débat depuis le temps hein ... ;)

Citation:

---

Envoyé par JolyLoic

Mais j'étais pas là à l'époque, alors que maintenant, je peux jouer aussi... Coucou

---

Avec plaisir :twisted:

Si tu tiens à lever une exception dans le constructeur, j'aurais plutôt utilisé un singleton et la fonction de création (avec paramètres) du singleton ressemblerait à :

Code:

---

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

Log * Log::s_log = 0; /*static*/ Log & Log::create_instance(params const & p) { try { s_log = new Log(p); return *s_log; } catch (std::exception & e) { Signaler l'erreur à qui pourrait s'en occuper ... Mais qui ? } s_log = new Log(); // le ctr par défaut étant no-throw // et si il y a un echec sur le new, on est bien embétés de toutes façons return *s_log; } /*static*/ Log & Log::instance() { assert(s_log); return *s_log; }

---

Citation:

---

Envoyé par Luc Hermitte

Si tu tiens à lever une exception dans le constructeur, j'aurais plutôt utilisé un singleton et la fonction de création (avec paramètres) du singleton ressemblerait à :

Code:

---

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

Log * Log::s_log = 0; /*static*/ Log & Log::create_instance(params const & p) { try { s_log = new Log(p); return *s_log; } catch (std::exception & e) { Signaler l'erreur à qui pourrait s'en occuper ... Mais qui ? } s_log = new Log(); // le ctr par défaut étant no-throw // et si il y a un echec sur le new, on est bien embétés de toutes façons return *s_log; } /*static*/ Log & Log::instance() { assert(s_log); return *s_log; }

---

---

En l'occurence c'était pas possible d'en faire un singleton, enfin si mais assez lourd, et dans mon catch je traite l'exception et ensuite le programme continue comme si de rien n'était. Pas besoin de signaler l'erreur, sauf à l'utilisateur, puisque la réussite de création de l'objet n'est pas vitale pour l'application, dans mon cas.
C'est vrai que si c'était un objet indispensable ca deviens très embêtant mais je n'aurais pas fait comme ca très certainement.

J'ouvre une toute petite parenthèse pour proposer un cas où la méthode init() me semble préférable : si l'objet est destiné à être réinitialisé. Mieux vaut créer une méthode init() appelée dans le constructeur et réinvocable plus tard, qu'une méthode reinit() qui ne ferait que recopier le code du constructeur (avec la dénormalisation qui va avec...).