[Style] Paramètres d'un constructeur => Structure

**rolkA** · 17/12/2004, 11h15

[Question par procuration d'un mec n'ayant pas internet]

Bonjour, dsl mais le nombre de caractères limité du titre ne me permet pas de bien décrire ma question
En fait, je voudrais savoir si c'est une bonne idée d'utiliser une structure pour chaque classe, qui servirait à initialiser le constructeur.

Par exemple, au lieu de faire çà:

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 C
{
    private:
        int m_a;
        int m_b;
        int m_p;
        //... + autres membres qui ne sont pas initialisés par l'utilsiateur de la classe...
 
    public:
        C(int a, long b, void* p);
};
 
...
 
C* c = new C(1, 2, NULL);

.. Faire ceci :

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
 
struct C_Init
{
    int a;
    long b;
    void* p;
};
 
class C
{
    private:
        int m_a;
        long m_b;
        void* m_p;
 
    public:
        C(const C_Init &init);
};
 
...
 
C_Init init;
init.a = 1;
init.b = 2;
init.p = NULL;
C* c = new C(init);

L'intérêt serait de ne pas avoir à changer le prototype du constructeur en cas de modification des paramètres d'initialisation... et le fait d'avoir une sorte d'initialisation "en colonne" plutot que "en ligne". Enfin bref...

=> qu'en pensez-vous ? (effets indésirés, lourdeur, etc ? [rolkA: vraiment lourd je trouve])
=> avez-vous déjà vu cette méthode employée quelquepart ? Dans une librairie par exemple ?

Merci d'avance

**tut** · 17/12/2004, 11h22

que se passera-t-il si effectivement la construction de ta classe change :
1 - il faudra mettre à jour le constructeur de ta classe;
2 - modifier les constructions de tes structures là où est appelé le constructeur de la classe.

Donc finalement, que gagneras-tu par rapport à une construction "classique" ?

**rolkA** · 17/12/2004, 11h28

salut tut. Je fais suivre ..... Réponse :

Tu n'es pas obligé de retoucher à toutes lignes ou il y a un construction. Si par exemple avec une même structure tu initialisés plusieurs class, moi je retouche un fois et toi autant de fois que tu appel le constructeur...

**tut** · 17/12/2004, 11h41

mouais, dans un cas particulier, ça peut être arrangeant.

Personnellement je préfèrerai utiliser la surcharge des constructeurs, ou un design pattern de factory.

Je trouve cette écriture plutôt lourde.
Mais, peut-être qu'il y a d'autres avantages qui m'échappent...

**chat hotplug** · 17/12/2004, 13h13

Moi ce qui m'embêterai c'est:

1) duplication de la declaration d'une sorte (d'un point de vue abstrait) ET donc possibilité de distribuer aleatoirement et n'importe comment des proprietes dans l'un ou l'autre schema.
2) redondance et plus de code... on est sensé gagné en temps de maintenance mais un code plus long est plus dur à maintenir... PARADOXE.
3) si on structure bien l'application en fichier on voudra idealement, programmation objet haut niveau d'abstraction oblige, avoir un code principal le plus concis possible.

Donc je deconseille totalement de proceder comme cela. Mieux vaut faire un peu plus de maintenance en cas de modification et bien documenter son code pour ça !

**mtopoloff** · 17/12/2004, 13h26

Et puis c'est moins lisible... L'objet A se contruit avec la strucutre B qui contient des objets C construits avec la strucutre D..... c'est lourd, illisible. Il faut simplifier au maximum.... Et au point de vu de la vitesse c'est pas top non plus.

**SKZ81** · 17/12/2004, 14h01

Envoyé par mtopoloff

Et au point de vu de la vitesse c'est pas top non plus.

Pas si sûr... Pense pas qu'il y ai énorme de difference entre une éxecution du PUSH ou de MOV (1°- empilement des arguments vs 2°-init des champs d'une structure) tant que la variable impliquée (fût-elle un champs de structure) ne contient pas de pointeurs (je veux dire par là que la l-value, dans le cas N°2 est une adresse directe) ; puisque dans le cas d'une structure (par rapport à une variable isolée int c; par exemple) le

Code :

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

MOV adresse, VALEUR

se transforme en

Code :

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

MOV adresse+OFFSET, VALEUR

D'ailleurs gcc place les argument dans la pile avec des MOV adresse+OFFSET, VALEUR et ne passe pas par push...

Envoyé par chat hotplug

2) redondance et plus de code... on est sensé gagné en temps de maintenance mais un code plus long est plus dur à maintenir... PARADOXE.

Vrai dans le cas général où on instancie les objets avec des valeurs qui varient en fonction de l'endrois dans le code !!
Si la structure n'est instanciée qu'une fois pour toutes et qu'on ne modifie pas ses valeurs, on réduite, non pas le nombre d'instructions, mais la complexité de celles-ci !!

Mais dans ce cas, la structure contenant ce qu'on peut alors apeller (mais ai-je bien compris le problème

: ) pourrait-être un membre de classe (static).
Ou encore mieux comme le signale tut, passer par une factory... I.e. un sigleton qui possède une instance de tous les objets, ce sont les "prototypes" de chaque clases, inité aux valeurs par défaut de contrustion des nouveaux objets.
A chaque fois que tu veux un nouvel objet, "yaka" apeller :

Code :

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

 Factory::getInstance()->new_MyObjet()

qui retournera un MyObjet* crée par le constructeur par copie, ayant pris en paramètre le prototype connue par l'instance de Factory.
En écrivant cette dernière ligne, je doute du fait que le Gang Des 4 ai défini la Factory comme singleton, puisque :
plusieurs Factory => plusieurs prototypes / classe => plusieurs contextes...

**rolkA** · 17/12/2004, 14h15

[rolkA]

Vrai dans le cas général où on instancie les objets avec des valeurs qui varient en fonction de l'endrois dans le code !!
Si la structure n'est instanciée qu'une fois pour toutes et qu'on ne modifie pas ses valeurs, on réduite, non pas le nombre d'instructions, mais la complexité de celles-ci !!

Mais mon pote préconise cette méthode pour TOUTES les classes... par exemple, initaliser un vaisseau avec sa position initiale.... et çà, çà change tout le temps....
C'est bien là que çà coince, je trouve, non ?
[/rolkA]

**Luc Hermitte** · 17/12/2004, 14h23

C'est inefficace au possible (pas forcément en terme de rapidité, quoique ...) mais en termes de maintenance et de simplicité d'utilisation.

Sous pretexte que les données à envoyer au constructeur pourraient changer, on utilise une structure qui fait double emploi avec le constructeur. Résultat, là où le compilateur nous aurait prévénu parce que l'on aurait oublié un paramètre dans le constructeur, on a une écriture verbeuse sur plusieurs lignes qui va passer sous silence les paramètres non initialisés ...
Super !

EDIT: le seul cas où je peux voir un intérêt à cela, c'est avec les mixin-classes (& -layers), dans la mesure où l'on ne peut pas savoir quels sont les classes que l'on a empilées et donc les constructeurs qui vont s'enchainer. Mais là, je pense que les "T().setx(x).sety(y)....;" sont plus "agréables" à utiliser.