Syntaxe : constructeur multiple

Bonjour

Comment avoir plusieurs constructeur pour la meme classe ?
Peuvent ils s'appeler mutuellement ?

Dans mes fonctions j'ai pour habitude d'en faire une "GROSSE" (complexe),
puis d'en faire des plus legeres qui l'appellent.
Je souhaite faire de meme pour mon constructeur
Expl Coté Déclaration

Code:

---

1 2 3 4 5 6 7 8 9

Type T_Ma_Classe = Class Private Composants... Public Constructor Create(Param_1,Param_2,Param_3:String);Overload; Constructor Create(Param_1,Param_3:String);Overload;//2eme Construct Constructor Create;Overload;//3eme construct

---

Coté Implementation

Code:

---

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

Constructor T_Ma_Classe.Create(Param_1,Param_2,Param_3:String); Begin VCL1 := TVCL1.Create(Nil); Bla bla.... End;   Constructor T_Ma_Classe.Create(Param_1,Param_3:String); Begin Create(Param_1,'Val_Param_2_Defaut',Param_3); End;   Constructor T_Ma_Classe.Create Begin Create('Val_Param_2_Defaut','Val_Param_2_Defaut','Val_Param_3_Defaut'); End;

---

Le compilateur ne m'a rien dit, mais coté execution,
n'aurais je pas des problemes ?
du genre : si j'appelle le 3eme Construct,
en fait j'aurais 2 instances en memoire, qui seront créées,
A cause du Create qui est appelé comme une vulgaire methode "normale" ?

Merci d'avance

Normalement ça ne pose pas de problème, pour exemple regarde l'implémentation de la classe TFileStream dans l'unité Classes.

Tu remarqueras que le constructeur à deux paramètres fait appel au constructeur à trois paramètres à l'intérieur de son implémentation (et sans la présence du mot clé inherited ;))

Sinon les paramètres par défaut ça existe si les constructeurs font tous la même chose (semble que oui si appelle chaîné)

Code:

---

1 2 3 4 5 6

Type T_Ma_Classe = Class Private Composants... Public Constructor Create(const Param_1:String = 'Val_Param_1_Defaut'; const const Param_2:String = 'Val_Param_2_Defaut'; const Param_3:String = 'Val_Param_3_Defaut');

---

C'est marrant, j'ai corrigé la même chose dans le code d'un collègue, la semaine dernière qui malheureusement dans l'une des variantes ne transmettaient pas les paramètres, conséquence un bug, ... autant s'éviter de la maintenance !

pour TFileStream, c'est particulier, car il y a un paramètre par défaut différent en fonction du sytème d'exploitation ... donc surcharge obligatoire ...

Non ce que tu veux faire est parfaitement légitime et fonctionne très bien. En fait, si un jour, au début de ton apprentissage du Delphi, tu as eu la fameuse violation d'accès sur l'exemple :

Code:

---

1 2 3 4 5

var List: TStringList; begin List.Create; // pas bien ! end;

---

Eh bien c'est lié.

D'abord, je vais rappeler la différence entre méthode d'instance et méthode de classe. Une méthode d'instance est déclarée de façon "normale", et doit être appelée sur une instance :

Code:

---

1 2 3 4 5 6 7 8 9 10

type TExample = class public procedure InstanceMethod(Param: Integer); end; ... var Example: TExample; ... Example.InstanceMethod(5);

---

Cet appel transmet en fait deux paramètres à InstanceMethod : le premier paramètre réel est Example, associé au paramètre formel Self (sous-entendu) de type TExample. Le second est bien sûr 5 associé au paramètre formel Param.

Une méthode de classe est déclarée avec le mot-clef class et doit (oui j'ai bien dit doit) être appelée sur une classe (en Delphi, une classe existe à l'exécution : leur type est appelé une métaclasse - voir tutoriel sur les métaclasses -, et généralement on peut y penser comme étant un pointeur sur un record particulier qui contient ses informations).

Code:

---

1 2 3 4 5 6 7

type TExample = class public class procedure ClassMethod(Param: Integer); end; ... TExample.ClassMethod(5);

---

Cet appel-ci transmet également deux paramètres à ClassMethod. Le premier réel est TExample, associé au paramètre formel Self, de type class of TExample cette fois ! Pour le second paramètre, 5 vs Param, pas de changement.

Si maintenant vous faites l'appel (qui est accepté par le compilateur, malgré le doit sur lequel j'ai insisté plus tôt) :

Code:

---

Example.ClassMethod(5);

---

Que penses-tu qui est transmis pour le paramètre formel Self ? La réponse n'est pas Example, mais bien Example.ClassType. ClassType est une fonction déclarée dans TObject. C'est ce qu'on appelle en réalité un sucre syntaxique.

Venons-en finalement aux constructeurs :)
Tout comme pour les méthodes de classe, la syntaxe permet les deux formes d'appel :

Code:

---

1 2 3 4

constructor Create(Param: Integer);   TExample.Create(5); Example.Create(5);

---

Cependant, contrairement aux méthodes de classes, ces deux formes ne sont pas sémantiquement équivalentes.

En fait, un constructeur possède 2 paramètres formels invisibles. Le premier est toujours Self, dont je vais dire pour l'instant qu'il est de type Pointer. Le second, je l'appellerai SelfIsClass (mais il n'est pas possible d'y accéder via le code Delphi - en ASM inline oui, mais on n'est pas là), et est de type Boolean.

Lorsqu'on fait l'appel :

Code:

---

TExample.Create(5);

---

Celui-ci est transformé par le compilateur en l'appel :

Code:

---

TExample$Create(Pointer(TExample), True, 5);

---

Si l'appel est sur un objet :

Code:

---

Example.Create(5);

---

Le code généré devient :

Code:

---

TExample$Create(Pointer(Example), False, 5);

---

Ainsi, le paramètre formel SelfIsClass indique, comme son nom le suggère, si le paramètre Self contient une classe (True) ou un objet (False).

Le début du code de tout constructeur (ce qui se passe dans le begin :p) pourrait être écrit (grossièrement, mais les détails sont hors sujet ici) en Delphi comme ceci (avec TExampleClass = class of TExample) :

Code:

---

1 2	if SelfIsClass then TExample(Self) := TExampleClass(Self).NewInstance;

---

Dès que le "begin est fini", Self contient donc toujours quelque chose qui est de type TExample (et non TExampleClass). Ainsi, pour le développeur, Self est de type TExample.

Finalement, lorsque, dans le corps d'un constructeur, vous écrivez :

Code:

---

1 2 3

Create(5, 'Param par défaut'); // ou même inherited Create(Param);

---

Ces deux appels sont effectués, bien sûr, sur Self, donc sur un objet, et donc avec comme valeur de SelfIsClass la valeur False.

Voilà, j'ai fini mon monologue :aie: J'espère que j'ai été clair :P

Merci SJRD, c'est une très bonne explication : très intéressante ! :king:
Cela a-t-il un lien avec TObject.InitInstance ?
Tu devrais nous mettre ça dans un tuto genre "Les Coulisses de l'Objet Delphi" :mouarf:

Citation:

---

Envoyé par ShaiLeTroll

Merci SJRD, c'est une très bonne explication : très intéressante ! :king:
Cela a-t-il un lien avec TObject.InitInstance ?

---

Absolument : la méthode NewInstance appelle InitInstance, entre autres ;)

Citation:

---

Envoyé par ShaiLeTroll

Tu devrais nous mettre ça dans un tuto genre "Les Coulisses de l'Objet Delphi" :mouarf:

---

Euh... Hum... En fait je suis en train d'écrire un livre là-dessus. Mais chuut ! C'est un secret :aie: (et en plus j'avance plus :?)

MErci a tous

Citation:

---

Envoyé par ShaiLeTroll

Sinon les paramètres par défaut ça existe si les constructeurs font tous la même chose (semble que oui si appelle chaîné)

---

J'y ai pensé mais comme par la suite les parametres seront de types differents, et il y aura des directives de compilations, j'ai opté pour prevoir le coup.
Ca m'evitera de changer le prototype en cours de route.
Ca fait un bail que je voulais utiliser de cette syntaxe, alors j'en profite pour me faire les dents:mrgreen:.

@Aka Guymelef
Tu as raison, c'est tout a fait ca, le systeme evoluera dans cette direction.

@sjrd
:king: La voilà une reponse quelle est chouette !explSi a mes debut, on m'avais tout expliqué comme ça !...
"Sucre Syntaxique" :bravo: J'adore - faut que je la resorte celle la 8-)
J'aurais au moin cette raison pour me proqurer ton Book :bug:
Ton explication est delicieuses(oui je suis un gourmand) : jai deja faim de ton livre - STOP au faillotage
Grand merci - quand j'aurais des Violation d'acces, je saurais que cela ne vient pas de là : je perdrais donc moins de temps