On peut utiliser this dans un constructeur pour accéder aux données membre
de l'instance. Cela veut-il dire que l'instance est créée dès que l'on entre
dans le constructeur ?
Dans le constructeur d'un objet A, peut-on appeler une méthode d'un autre
objet B qui a besoin de l'objet A en paramètre, donc de this ?
Sauf erreur, ça me parait tout à fait possible. Dans le constructeur, on peut accéder aux données membres, donc l'instance est déjà créée en mémoire.
Bonne continuation,
Mitsuru FURUTA [Microsoft FRANCE]
"ShadowFil" wrote in message news:
Bonjour,
On peut utiliser this dans un constructeur pour accéder aux données membre de l'instance. Cela veut-il dire que l'instance est créée dès que l'on
entre
dans le constructeur ?
Dans le constructeur d'un objet A, peut-on appeler une méthode d'un autre objet B qui a besoin de l'objet A en paramètre, donc de this ?
Exemple :
class myClass {
}
Merci de votre aide.
Zazar
Bonjour,
On peut utiliser this dans un constructeur pour accéder aux données membre de l'instance. Cela veut-il dire que l'instance est créée dès que l'on
entre
dans le constructeur ?
Comme son nom ne l'indique pas, un constructeur ne constuit pas l'objet. C'est juste une méthode qui est appelée aprés la construction de l'objet et qui sert à initialiser des variables membres de l'objet. Il n'est même pas garanti que le constructeur de l'objet soit appelé alors que l'objet est construit.
Dans le constructeur d'un objet A, peut-on appeler une méthode d'un autre objet B qui a besoin de l'objet A en paramètre, donc de this ?
En théorie, oui on peut. En pratique : 1) si B fait appel à des méthodes virtuelles de A, on risque d'avoir de jolies surprises
class MyClass1 { MyClass1() { B.Use(this); } public virtual void DoSomething() { ... } }
class MyClass2 { private string myStr; public MyClass2(string oneString) { if (oneString == null) throw new Exception(); myStr = oneString; } public override void DoSomething() { DoOtherthing(myStr.IndexOf("azerty")); base.DoSomething } }
Le constructeur de MyClass1 est appelé avant celui de MyClass2. la variable myStr n'est donc pas initialisée au moment de l'appel à B.Use(this); Si B.use() appelle la méthode DoSomething(), il va y avoir une nullpointerexception car c'est la méthode de MyClass2 qui va être appelée.
2) ce n'est pas une bonne idée. Un constructeur ne devrait servir qu'à initialiser des données. Si vous avez besoin de passer l'objet à une autre variable faîte le à un autre moment.
Exemple :
class myClass {
}
Je n'ai rien à reprocher à votre exemple. :)
-- Zazar
Bonjour,
On peut utiliser this dans un constructeur pour accéder aux données membre
de l'instance. Cela veut-il dire que l'instance est créée dès que l'on
entre
dans le constructeur ?
Comme son nom ne l'indique pas, un constructeur ne constuit pas l'objet.
C'est juste une méthode qui est appelée aprés la construction de l'objet et
qui sert à initialiser des variables membres de l'objet. Il n'est même pas
garanti que le constructeur de l'objet soit appelé alors que l'objet est
construit.
Dans le constructeur d'un objet A, peut-on appeler une méthode d'un autre
objet B qui a besoin de l'objet A en paramètre, donc de this ?
En théorie, oui on peut. En pratique :
1) si B fait appel à des méthodes virtuelles de A, on risque d'avoir de
jolies surprises
class MyClass1 {
MyClass1() {
B.Use(this);
}
public virtual void DoSomething() {
...
}
}
class MyClass2 {
private string myStr;
public MyClass2(string oneString) {
if (oneString == null)
throw new Exception();
myStr = oneString;
}
public override void DoSomething() {
DoOtherthing(myStr.IndexOf("azerty"));
base.DoSomething
}
}
Le constructeur de MyClass1 est appelé avant celui de MyClass2. la variable
myStr n'est donc pas initialisée au moment de l'appel à B.Use(this);
Si B.use() appelle la méthode DoSomething(), il va y avoir une
nullpointerexception car c'est la méthode de MyClass2 qui va être appelée.
2) ce n'est pas une bonne idée.
Un constructeur ne devrait servir qu'à initialiser des données. Si vous avez
besoin de passer l'objet à une autre variable faîte le à un autre moment.
On peut utiliser this dans un constructeur pour accéder aux données membre de l'instance. Cela veut-il dire que l'instance est créée dès que l'on
entre
dans le constructeur ?
Comme son nom ne l'indique pas, un constructeur ne constuit pas l'objet. C'est juste une méthode qui est appelée aprés la construction de l'objet et qui sert à initialiser des variables membres de l'objet. Il n'est même pas garanti que le constructeur de l'objet soit appelé alors que l'objet est construit.
Dans le constructeur d'un objet A, peut-on appeler une méthode d'un autre objet B qui a besoin de l'objet A en paramètre, donc de this ?
En théorie, oui on peut. En pratique : 1) si B fait appel à des méthodes virtuelles de A, on risque d'avoir de jolies surprises
class MyClass1 { MyClass1() { B.Use(this); } public virtual void DoSomething() { ... } }
class MyClass2 { private string myStr; public MyClass2(string oneString) { if (oneString == null) throw new Exception(); myStr = oneString; } public override void DoSomething() { DoOtherthing(myStr.IndexOf("azerty")); base.DoSomething } }
Le constructeur de MyClass1 est appelé avant celui de MyClass2. la variable myStr n'est donc pas initialisée au moment de l'appel à B.Use(this); Si B.use() appelle la méthode DoSomething(), il va y avoir une nullpointerexception car c'est la méthode de MyClass2 qui va être appelée.
2) ce n'est pas une bonne idée. Un constructeur ne devrait servir qu'à initialiser des données. Si vous avez besoin de passer l'objet à une autre variable faîte le à un autre moment.
Exemple :
class myClass {
}
Je n'ai rien à reprocher à votre exemple. :)
-- Zazar
Faust
>> Dans le constructeur d'un objet A, peut-on appeler une méthode d'un autre objet B qui a besoin de l'objet A en paramètre, donc de this ?
En théorie, oui on peut. En pratique : 1) si B fait appel à des méthodes virtuelles de A, on risque d'avoir de jolies surprises
class MyClass1 { MyClass1() { B.Use(this); } public virtual void DoSomething() { ... } }
class MyClass2 { private string myStr; public MyClass2(string oneString) { if (oneString == null) throw new Exception(); myStr = oneString; } public override void DoSomething() { DoOtherthing(myStr.IndexOf("azerty")); base.DoSomething } }
Le constructeur de MyClass1 est appelé avant celui de MyClass2. la variable myStr n'est donc pas initialisée au moment de l'appel à B.Use(this);
forcément puisque dans ton exemple, B n'est pas initialisé! mais en ayant mis MyClass2 B = new MyClass2(''); avant, B devient intialisé et myStr aussi
Si B.use() appelle la méthode DoSomething(), il va y avoir une nullpointerexception car c'est la méthode de MyClass2 qui va être appelée.
2) ce n'est pas une bonne idée. Un constructeur ne devrait servir qu'à initialiser des données. Si vous avez besoin de passer l'objet à une autre variable faîte le à un autre moment.
au contraire, ce type d'utilisation est très courament utilisée et fonctionne très bien il faut juste s'assurer que les propriétés de A dont va avoir besoin l'objet B sont prêtes et initialisées. Heureusement encore, que ça fonctionne, sinon on passerait son temps à écrire:
MyObject A = new MyObject(); A.InitialiserObject();
-- Faust
>> Dans le constructeur d'un objet A, peut-on appeler une méthode d'un autre
objet B qui a besoin de l'objet A en paramètre, donc de this ?
En théorie, oui on peut. En pratique :
1) si B fait appel à des méthodes virtuelles de A, on risque d'avoir de
jolies surprises
class MyClass1 {
MyClass1() {
B.Use(this);
}
public virtual void DoSomething() {
...
}
}
class MyClass2 {
private string myStr;
public MyClass2(string oneString) {
if (oneString == null)
throw new Exception();
myStr = oneString;
}
public override void DoSomething() {
DoOtherthing(myStr.IndexOf("azerty"));
base.DoSomething
}
}
Le constructeur de MyClass1 est appelé avant celui de MyClass2. la variable
myStr n'est donc pas initialisée au moment de l'appel à B.Use(this);
forcément puisque dans ton exemple, B n'est pas initialisé!
mais en ayant mis
MyClass2 B = new MyClass2('');
avant, B devient intialisé et myStr aussi
Si B.use() appelle la méthode DoSomething(), il va y avoir une
nullpointerexception car c'est la méthode de MyClass2 qui va être appelée.
2) ce n'est pas une bonne idée.
Un constructeur ne devrait servir qu'à initialiser des données. Si vous avez
besoin de passer l'objet à une autre variable faîte le à un autre moment.
au contraire, ce type d'utilisation est très courament utilisée et
fonctionne très bien
il faut juste s'assurer que les propriétés de A dont va avoir besoin
l'objet B sont prêtes et initialisées.
Heureusement encore, que ça fonctionne, sinon on passerait son temps à
écrire:
MyObject A = new MyObject();
A.InitialiserObject();
>> Dans le constructeur d'un objet A, peut-on appeler une méthode d'un autre objet B qui a besoin de l'objet A en paramètre, donc de this ?
En théorie, oui on peut. En pratique : 1) si B fait appel à des méthodes virtuelles de A, on risque d'avoir de jolies surprises
class MyClass1 { MyClass1() { B.Use(this); } public virtual void DoSomething() { ... } }
class MyClass2 { private string myStr; public MyClass2(string oneString) { if (oneString == null) throw new Exception(); myStr = oneString; } public override void DoSomething() { DoOtherthing(myStr.IndexOf("azerty")); base.DoSomething } }
Le constructeur de MyClass1 est appelé avant celui de MyClass2. la variable myStr n'est donc pas initialisée au moment de l'appel à B.Use(this);
forcément puisque dans ton exemple, B n'est pas initialisé! mais en ayant mis MyClass2 B = new MyClass2(''); avant, B devient intialisé et myStr aussi
Si B.use() appelle la méthode DoSomething(), il va y avoir une nullpointerexception car c'est la méthode de MyClass2 qui va être appelée.
2) ce n'est pas une bonne idée. Un constructeur ne devrait servir qu'à initialiser des données. Si vous avez besoin de passer l'objet à une autre variable faîte le à un autre moment.
au contraire, ce type d'utilisation est très courament utilisée et fonctionne très bien il faut juste s'assurer que les propriétés de A dont va avoir besoin l'objet B sont prêtes et initialisées. Heureusement encore, que ça fonctionne, sinon on passerait son temps à écrire:
MyObject A = new MyObject(); A.InitialiserObject();
-- Faust
Zazar
> forcément puisque dans ton exemple, B n'est pas initialisé! mais en ayant mis MyClass2 B = new MyClass2(''); avant, B devient intialisé et myStr aussi
J'avais interprété B comme étant une autre classe (notation microsoft) et j'ai supposé qu'elle possèdait une méthode Use prenant en paramètre un objet de type MyClass1(). Mais en fait peu importe ce que c'est, le but c'est que dans le constructeur de MyClass1, on fasse appel à la méthode DoSomething() d'une manière ou d'une autre : vous pouvez même mettre tout simplement DoSomething() sans faire appel à un objet externe. Dans tous les cas, vous aurez une exception.
2) ce n'est pas une bonne idée. Un constructeur ne devrait servir qu'à initialiser des données. Si vous avez besoin de passer l'objet à une autre variable faîte le à un autre moment.
au contraire, ce type d'utilisation est très courament utilisée et fonctionne très bien
Je précise mon affirmation : tout dépend de ce que fait la méthode de l'objet B. Si elle fait du pur calcul en n'utilisant aucune méthode virtuelle de A : ok. Si elle modifie l'état de tout autre objet que l'objet nouvellement créé, alors non, il ne faut pas l'appeler. Comme dit dans mon post précédent, le constructeur ne devrait servir qu'à initialiser l'objet, mais effectivement si celui-ci a besoin d'appeler une autre méthode pour s'initialiser, il ne faut évidemment pas s'en priver.
-- Zazar
> forcément puisque dans ton exemple, B n'est pas initialisé!
mais en ayant mis
MyClass2 B = new MyClass2('');
avant, B devient intialisé et myStr aussi
J'avais interprété B comme étant une autre classe (notation microsoft) et
j'ai supposé qu'elle possèdait une méthode Use prenant en paramètre un objet
de type MyClass1(). Mais en fait peu importe ce que c'est, le but c'est que
dans le constructeur de MyClass1, on fasse appel à la méthode DoSomething()
d'une manière ou d'une autre : vous pouvez même mettre tout simplement
DoSomething() sans faire appel à un objet externe. Dans tous les cas, vous
aurez une exception.
2) ce n'est pas une bonne idée.
Un constructeur ne devrait servir qu'à initialiser des données. Si vous
avez
besoin de passer l'objet à une autre variable faîte le à un autre moment.
au contraire, ce type d'utilisation est très courament utilisée et
fonctionne très bien
Je précise mon affirmation : tout dépend de ce que fait la méthode de
l'objet B. Si elle fait du pur calcul en n'utilisant aucune méthode
virtuelle de A : ok. Si elle modifie l'état de tout autre objet que l'objet
nouvellement créé, alors non, il ne faut pas l'appeler. Comme dit dans mon
post précédent, le constructeur ne devrait servir qu'à initialiser l'objet,
mais effectivement si celui-ci a besoin d'appeler une autre méthode pour
s'initialiser, il ne faut évidemment pas s'en priver.
> forcément puisque dans ton exemple, B n'est pas initialisé! mais en ayant mis MyClass2 B = new MyClass2(''); avant, B devient intialisé et myStr aussi
J'avais interprété B comme étant une autre classe (notation microsoft) et j'ai supposé qu'elle possèdait une méthode Use prenant en paramètre un objet de type MyClass1(). Mais en fait peu importe ce que c'est, le but c'est que dans le constructeur de MyClass1, on fasse appel à la méthode DoSomething() d'une manière ou d'une autre : vous pouvez même mettre tout simplement DoSomething() sans faire appel à un objet externe. Dans tous les cas, vous aurez une exception.
2) ce n'est pas une bonne idée. Un constructeur ne devrait servir qu'à initialiser des données. Si vous avez besoin de passer l'objet à une autre variable faîte le à un autre moment.
au contraire, ce type d'utilisation est très courament utilisée et fonctionne très bien
Je précise mon affirmation : tout dépend de ce que fait la méthode de l'objet B. Si elle fait du pur calcul en n'utilisant aucune méthode virtuelle de A : ok. Si elle modifie l'état de tout autre objet que l'objet nouvellement créé, alors non, il ne faut pas l'appeler. Comme dit dans mon post précédent, le constructeur ne devrait servir qu'à initialiser l'objet, mais effectivement si celui-ci a besoin d'appeler une autre méthode pour s'initialiser, il ne faut évidemment pas s'en priver.
