System.out.println(f.var); // lequel il va ecrire ? attribut var de Fils ou celui // du pere...
utilise plutot deux variables de classes dont le nom est different
Nicolas Delsaux
Le 22.10 2003, (laurent) s'est levé(e) et s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"
Selon moi je le deconseillerai car si tu fais:
Fils f = new Fils();
System.out.println(f.var); // lequel il va ecrire ? attribut var de Fils ou celui // du pere...
La réponse est assez simple : celle du fils. C'est à ça que sert la surcharge, très précisément.
utilise plutot deux variables de classes dont le nom est different
C'est aussi ce que je dirais.
-- Nicolas Delsaux "S'il existe deux ou plusieurs manières de faire quelque chose et que l'une de ces manières est susceptible de se solder par une catastrophe, on peut être certain que quelqu'un se débrouillera pour la choisir." Edward A.Murphy Jr
Le 22.10 2003, ryleland@yahoo.fr (laurent) s'est levé(e) et s'est dit
"tiens, je vais écrire aux mecs de fr.comp.lang.java"
Selon moi je le deconseillerai car si tu fais:
Fils f = new Fils();
System.out.println(f.var); // lequel il va ecrire ? attribut var de
Fils ou celui
// du pere...
La réponse est assez simple : celle du fils. C'est à ça que sert la
surcharge, très précisément.
utilise plutot deux variables de classes dont le nom est different
C'est aussi ce que je dirais.
--
Nicolas Delsaux
"S'il existe deux ou plusieurs manières de faire quelque chose et que l'une
de ces manières est susceptible de se solder par une catastrophe, on peut
être certain que quelqu'un se débrouillera pour la choisir."
Edward A.Murphy Jr
Le 22.10 2003, (laurent) s'est levé(e) et s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"
Selon moi je le deconseillerai car si tu fais:
Fils f = new Fils();
System.out.println(f.var); // lequel il va ecrire ? attribut var de Fils ou celui // du pere...
La réponse est assez simple : celle du fils. C'est à ça que sert la surcharge, très précisément.
utilise plutot deux variables de classes dont le nom est different
C'est aussi ce que je dirais.
-- Nicolas Delsaux "S'il existe deux ou plusieurs manières de faire quelque chose et que l'une de ces manières est susceptible de se solder par une catastrophe, on peut être certain que quelqu'un se débrouillera pour la choisir." Edward A.Murphy Jr
Nicolas Delsaux
Le 22.10 2003, "xav14" s'est levé(e) et s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"
Pour préciser, en fait j'ai un attribut dans la classe pere qui est variable et je veux le rendre constant dans une classe dérivée.
Je suppose que tu utilise pour cet attribut des getters et des setters (en
clair une méthode setVar(int newVar) et une méthode getVar()) et que partout dans tes classes Pere et Fils tu accèdesz à cet attribut par le biais de ces méthodes ? Si c'est le cas, tu n'as qu'à surcharger la méthode setVar(int newVar) pour qu'elle ne fasse rien. Si ça n'est pas le cas, fais en sorte que ça le soit, ça va grandement te simplifier la vie (et tu n'auras par ailleurs pas à définir de variable var final, ce qui de toute façon risque de ne pas marcher, à cause du masquage des variables).
-- Nicolas Delsaux "Celui qui sait en quoi consiste l'action humaine nourrit ce que sa conscience saisit au moyen de ce qu'elle ne saisit pas." Tchouang-Tseu
Le 22.10 2003, "xav14" <xav14@free.fr> s'est levé(e) et s'est dit
"tiens, je vais écrire aux mecs de fr.comp.lang.java"
Pour préciser, en fait j'ai un attribut dans la classe pere qui est
variable et je veux le rendre constant dans une classe dérivée.
Je suppose que tu utilise pour cet attribut des getters et des setters (en
clair une méthode setVar(int newVar) et une méthode getVar()) et que
partout dans tes classes Pere et Fils tu accèdesz à cet attribut par le
biais de ces méthodes ?
Si c'est le cas, tu n'as qu'à surcharger la méthode setVar(int newVar) pour
qu'elle ne fasse rien.
Si ça n'est pas le cas, fais en sorte que ça le soit, ça va grandement te
simplifier la vie (et tu n'auras par ailleurs pas à définir de variable var
final, ce qui de toute façon risque de ne pas marcher, à cause du masquage
des variables).
--
Nicolas Delsaux
"Celui qui sait en quoi consiste l'action humaine nourrit ce que sa
conscience saisit au moyen de ce qu'elle ne saisit pas."
Tchouang-Tseu
Le 22.10 2003, "xav14" s'est levé(e) et s'est dit "tiens, je vais écrire aux mecs de fr.comp.lang.java"
Pour préciser, en fait j'ai un attribut dans la classe pere qui est variable et je veux le rendre constant dans une classe dérivée.
Je suppose que tu utilise pour cet attribut des getters et des setters (en
clair une méthode setVar(int newVar) et une méthode getVar()) et que partout dans tes classes Pere et Fils tu accèdesz à cet attribut par le biais de ces méthodes ? Si c'est le cas, tu n'as qu'à surcharger la méthode setVar(int newVar) pour qu'elle ne fasse rien. Si ça n'est pas le cas, fais en sorte que ça le soit, ça va grandement te simplifier la vie (et tu n'auras par ailleurs pas à définir de variable var final, ce qui de toute façon risque de ne pas marcher, à cause du masquage des variables).
-- Nicolas Delsaux "Celui qui sait en quoi consiste l'action humaine nourrit ce que sa conscience saisit au moyen de ce qu'elle ne saisit pas." Tchouang-Tseu
Kupee
laurent wrote:
Selon moi je le deconseillerai car si tu fais:
Fils f = new Fils();
System.out.println(f.var); // lequel il va ecrire ? attribut var de Fils ou celui // du pere...
utilise plutot deux variables de classes dont le nom est different
Ca c'est clair, surcharger un champ ca attire que des emmerdes, imagine que là System.out.println(f.var) va écrire le champ var du fils, alors que si on avait fait Pere p = new Fils(); System.out.println(p.var); on écrirait celui du père. Et plus tordu
Fils f = new Fils(); System.out.println(f.var); System.out.println(((Pere) f).var); écrira sucessivement celui du fils puis du père
laurent wrote:
Selon moi je le deconseillerai car si tu fais:
Fils f = new Fils();
System.out.println(f.var); // lequel il va ecrire ? attribut var de Fils ou celui
// du pere...
utilise plutot deux variables de classes dont le nom est different
Ca c'est clair, surcharger un champ ca attire que des emmerdes, imagine
que là
System.out.println(f.var) va écrire le champ var du fils, alors que si
on avait fait
Pere p = new Fils();
System.out.println(p.var);
on écrirait celui du père.
Et plus tordu
Fils f = new Fils();
System.out.println(f.var);
System.out.println(((Pere) f).var); écrira sucessivement celui du fils
puis du père
System.out.println(f.var); // lequel il va ecrire ? attribut var de Fils ou celui // du pere...
utilise plutot deux variables de classes dont le nom est different
Ca c'est clair, surcharger un champ ca attire que des emmerdes, imagine que là System.out.println(f.var) va écrire le champ var du fils, alors que si on avait fait Pere p = new Fils(); System.out.println(p.var); on écrirait celui du père. Et plus tordu
Fils f = new Fils(); System.out.println(f.var); System.out.println(((Pere) f).var); écrira sucessivement celui du fils puis du père
Akram
en effet, c est tres mal. Si tes deux classes n'ont rien en commun pourquoi faire de l'heritage? pourquoi ne pas créer un autre attribut? as-tu penser à mettre l'attribut en protected?
xav14 wrote:
From: "xav14"
abstract public class Pere { public int var=1; ...
public class Fils extends Pere { public final int var=1; ... }
Est-ce que c'est correct de faire ça ? déconseillé ? mal ? A priori le abstract n'a pas d'importance mais peut-il en avoir ?
Merci pour les réponse.
@+ Xav14
Pour préciser, en fait j'ai un attribut dans la classe pere qui est variable et je veux le rendre constant dans une classe dérivée.
en effet, c est tres mal.
Si tes deux classes n'ont rien en commun pourquoi faire de l'heritage?
pourquoi ne pas créer un autre attribut? as-tu penser à mettre
l'attribut en protected?
xav14 wrote:
From: "xav14" <xav14@free.fr>
abstract public class Pere {
public int var=1;
...
public class Fils extends Pere {
public final int var=1;
...
}
Est-ce que c'est correct de faire ça ? déconseillé ? mal ?
A priori le abstract n'a pas d'importance mais peut-il en avoir ?
Merci pour les réponse.
@+
Xav14
Pour préciser, en fait j'ai un attribut dans la classe pere qui est variable
et je veux le rendre constant dans une classe dérivée.
en effet, c est tres mal. Si tes deux classes n'ont rien en commun pourquoi faire de l'heritage? pourquoi ne pas créer un autre attribut? as-tu penser à mettre l'attribut en protected?
xav14 wrote:
From: "xav14"
abstract public class Pere { public int var=1; ...
public class Fils extends Pere { public final int var=1; ... }
Est-ce que c'est correct de faire ça ? déconseillé ? mal ? A priori le abstract n'a pas d'importance mais peut-il en avoir ?
Merci pour les réponse.
@+ Xav14
Pour préciser, en fait j'ai un attribut dans la classe pere qui est variable et je veux le rendre constant dans une classe dérivée.
xav14
"Akram" a écrit dans le message de news:bn6tgb$1mq1$
en effet, c est tres mal. Si tes deux classes n'ont rien en commun pourquoi faire de l'heritage? pourquoi ne pas créer un autre attribut? as-tu penser à mettre l'attribut en protected?
J'ai simplifié au maximum pour l'exemple. Elles ont d'autres champs en commun. Mais la surcharge du setter est la meilleure solution.
"Akram" <akram@free.fr> a écrit dans le message de
news:bn6tgb$1mq1$2@biggoron.nerim.net...
en effet, c est tres mal.
Si tes deux classes n'ont rien en commun pourquoi faire de l'heritage?
pourquoi ne pas créer un autre attribut? as-tu penser à mettre
l'attribut en protected?
J'ai simplifié au maximum pour l'exemple. Elles ont d'autres champs en
commun. Mais la surcharge du setter est la meilleure solution.
"Akram" a écrit dans le message de news:bn6tgb$1mq1$
en effet, c est tres mal. Si tes deux classes n'ont rien en commun pourquoi faire de l'heritage? pourquoi ne pas créer un autre attribut? as-tu penser à mettre l'attribut en protected?
J'ai simplifié au maximum pour l'exemple. Elles ont d'autres champs en commun. Mais la surcharge du setter est la meilleure solution.
Vincent Brabant
Ca c'est clair, surcharger un champ ca attire que des emmerdes, imagine que là System.out.println(f.var) va écrire le champ var du fils, alors que si on avait fait Pere p = new Fils(); System.out.println(p.var); on écrirait celui du père. Et plus tordu
Fils f = new Fils(); System.out.println(f.var); System.out.println(((Pere) f).var); écrira sucessivement celui du fils puis du père
J'ai eu du mal à le croire lorsque j'ai lu ce code. Mais c'est vrai.
On en apprend tous les jours ici.
Merci.
Vincent
Ca c'est clair, surcharger un champ ca attire que des emmerdes, imagine
que là
System.out.println(f.var) va écrire le champ var du fils, alors que si
on avait fait
Pere p = new Fils();
System.out.println(p.var);
on écrirait celui du père.
Et plus tordu
Fils f = new Fils();
System.out.println(f.var);
System.out.println(((Pere) f).var); écrira sucessivement celui du fils
puis du père
J'ai eu du mal à le croire lorsque j'ai lu ce code. Mais c'est vrai.
Ca c'est clair, surcharger un champ ca attire que des emmerdes, imagine que là System.out.println(f.var) va écrire le champ var du fils, alors que si on avait fait Pere p = new Fils(); System.out.println(p.var); on écrirait celui du père. Et plus tordu
Fils f = new Fils(); System.out.println(f.var); System.out.println(((Pere) f).var); écrira sucessivement celui du fils puis du père
J'ai eu du mal à le croire lorsque j'ai lu ce code. Mais c'est vrai.
On en apprend tous les jours ici.
Merci.
Vincent
Jc Sirot
xav14 wrote:
abstract public class Pere { public int var=1; ...
public class Fils extends Pere { public final int var=1; ... }
Est-ce que c'est correct de faire ça ? déconseillé ? mal ? A priori le abstract n'a pas d'importance mais peut-il en avoir ?
D'une façon générale il faut toujours essayer d'éviter les champs qui ne sont pas déclarés private ou public/package static final et utiliser des methodes get et set pour accéder aux variables d'instance.
--
Cordialement -- JC Sirot
xav14 wrote:
abstract public class Pere {
public int var=1;
...
public class Fils extends Pere {
public final int var=1;
...
}
Est-ce que c'est correct de faire ça ? déconseillé ? mal ?
A priori le abstract n'a pas d'importance mais peut-il en avoir ?
D'une façon générale il faut toujours essayer d'éviter les champs qui ne
sont pas déclarés private ou public/package static final et utiliser des
methodes get et set pour accéder aux variables d'instance.
abstract public class Pere { public int var=1; ...
public class Fils extends Pere { public final int var=1; ... }
Est-ce que c'est correct de faire ça ? déconseillé ? mal ? A priori le abstract n'a pas d'importance mais peut-il en avoir ?
D'une façon générale il faut toujours essayer d'éviter les champs qui ne sont pas déclarés private ou public/package static final et utiliser des methodes get et set pour accéder aux variables d'instance.
