Discussion :

[bulbo]

Bonjour les gens,

Bon comme on est vendredi et que je m'ennuie j'ai deux questions existentielles qui me turlupinent.

NDLR: tout les tests ont ete fait avec un JDK 1.6 a jour de ses updates.

Question 1: Vous trouvez normal que ce code fonctionne ?

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
public class C
{
 
  private String name;
 
  public C()
  {
    name = "C";
  }
 
  public void affiche(C aC)
  {
    System.out.println(aC.name);
  }
 
  public String getName()
  {
    return name;
  }
 
  public static void main(String args[])
  {
    C coucou = new C();
    coucou.affiche(coucou);
  }
}

Moi j'etais reste sur l'idee bete que private bah c'etait private a l'instance mais apparemment pas Ca vous choque vous aussi ?

Question 2: Toute mon estime a celui qui
1 - me donne l'output de l'execution (sans tricher, attention je verifierai si vous l'avez fait tourner avant de repondre )
2 - me donne une explication claire et rationnelle, regardant la philosophie objet du pourquoi ca a ete fait comme ca.
3 - me donne l'age du capitaine

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
package dummy;
 
public class A
{
  protected String name; 
 
  public A()
  {
    name = "A";
  }
 
  public void affiche(A a)
  {
    System.out.println(a.name);
    System.out.println("inA:" + name);
  }
 
  public static void main(String args[])
  {
    B bidule = new B();
    A toto = bidule;
 
    bidule.affiche(bidule);
    toto.affiche(bidule);
 
    bidule.affiche(toto);
    toto.affiche(toto);
  }
}
 
package dummy;
 
public class B extends A
{
  public String name;
 
  public B()
  {
    name = "B";
  }
 
  public void affiche(B b)
  {
    System.out.println(b.name);
    System.out.println("inB:" + name);
  }
 
  public void affiche(A a)
  {
    System.out.println(a.name);
    System.out.println("inB:" + name);
  }
}

Et la reponse c'est vendredi, t'es creve va te coucher n'est pas pas acceptable

Bulbo

[®om]

Pour la première question, ça m'avait surpris en 1ère année de DUT. La visibilité private correspond à la classe, mais pas à l'instance.
Par contre pour protected, c'est différent pour l'héritage. Si B extends A (dans un package différent) et que A a un attribut protected, dans l'instance de B tu as le droit d'y accéder, mais si tu fais une méthode affiche(B b) tu n'as pas le droit de faire b.tonAttribut.
J'aurais été plus vite à faire un exemple qu'à le décrire, mais maintenant que c'est fait, tant pis lol...

Pour la 2e question, ça m'avait surpris en 1ère année d'école d'ingénieurs, on avait eu cette question en TD (et je m'étais fait avoir). C'est simplement parce que le choix de la signature de la méthode appelée au sein de la même classe (entre affiche(A) et affiche(B)) est déterminé à la compilation, par contre la méthode à appeler (au sein de toute la hiérarchie) est déterminée à l'exécution.
EDIT: et un truc qui doit t'embrouiller, c'est que ton attribut name protected dans A est caché par ton attribut name public dans b (tu as 2 attributs name) dans b en fait... dont un est inaccessible... sauf si l'objet apparent (c'est déterminé à la compilation) est de type A, auquel cas tu peux y accéder

[bulbo]

Je suis pas tout a fait d'accord avec toi.

Si tu regardes les traces de l'execution tu verras que ce sont toujours les methodes declarees dans B qui sont appellees donc ce n'est pas la resolution de la methode qui pose probleme.

Moi ce qui me pose probleme c'est que suivant le type de declaration d'une variable une meme methode, appellee sur un meme objet, avec le meme argument (c'est facile en meme temps j'ai qu'un seul objet dans mon truc ) donne un resultat different.

Genre l'appel:

Code :

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

toto.affiche(bidule)

La methode finalement resolue est celle declaree dans B, l'argument est de type B, seulement la variable n'est pas celle visible dans B, mais celle visible dans A or on accede bien a un B.name dans cette fichue methode non ?

Apres question logique et optimisation memoire: pourquoi creer une variable si celle ci est masquee par une autre definition.
De ce que je me rappelle de mes cours d'objets et de liaison dynamique, les instances contiennent les variables d'instances (ou au moins leur reference), si elle est masquee par une autre elle ne devrait pas exister point final.

Et ton explication ne repond pas (donc pas de medaillle en chocolat) a:
Pourquoi avoir fait comme cela ?

Bulbo

[®om]

Si tu regardes les traces de l'execution tu verras que ce sont toujours les methodes declarees dans B qui sont appellees donc ce n'est pas la resolution de la methode qui pose probleme.

Une méthode est déterminée par 2 choses:
- la classe dans laquelle elle se trouve
- le nombre et le type de ses arguments

La première chose est déterminée à l'exécution.
La seconde chose est déterminée à la compilation.

Comme tu appelles afficher(...) sur un objet de type B, et que la méthode présente dans A est overridée dans B, tu appelles forcément la méthode se trouvant dans la classe B (car déterminé à l'exécution -> type réel utilisé).

Moi ce qui me pose probleme c'est que suivant le type de declaration d'une variable une meme methode, appellee sur un meme objet, avec le meme argument (c'est facile en meme temps j'ai qu'un seul objet dans mon truc ) donne un resultat different.

Justement parce que le choix de la méthode (au niveau de sa signature) en fonction du type des arguments est déterminé à la compilation. Donc le compilateur dit "affiche(A)" sera appelé par exemple. Mais ne dit pas si c'est affiche(A) de A ou affiche(A) de B (ça sera fait à l'exécution).

La methode finalement resolue est celle declaree dans B, l'argument est de type B, seulement la variable n'est pas celle visible dans B, mais celle visible dans A or on accede bien a un B.name dans cette fichue methode non ?

Apres question logique et optimisation memoire: pourquoi creer une variable si celle ci est masquee par une autre definition.
De ce que je me rappelle de mes cours d'objets et de liaison dynamique, les instances contiennent les variables d'instances (ou au moins leur reference), si elle est masquee par une autre elle ne devrait pas exister point final.

Ça n'est pas parce qu'une variable est masquée (non nommable -et encore pour protected elle est nommable-) qu'elle n'existe pas...

Par exemple:

Code :

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

1
2
3
4
5
6
7
8
9
class A {
    protected int x;
    public int getAX() { return x; }
}
class B extends A {
    protected int x;
    public int getBX() { return x + getAX(); }
    //ou encore A.this.x si on veut la nommer
}

C'est d'ailleurs ce qui se passe pour toutes les variables privées. Dans une sous-classe, tu ne peux pas les nommer, pourtant elles sont bien présentes dans ton instance sur le "heap" à l'exécution.

Et ton explication ne repond pas (donc pas de medaillle en chocolat) a:
Pourquoi avoir fait comme cela ?

La détermination de la bonne méthode à l'exécution (la liaison tardive) entraîne déjà un (petit) coût à l'exécution, mais c'est évidemment quelque chose de très important.
Cependant, la détermination dynamique d'une méthode parmi plusieurs ayant le même nom mais des types d'arguments différents entraînerait un coût encore plus important (et pas aussi peu cher que la liaison tardive) au runtime, alors que ça ne sert à rien... Alors c'est le compilateur qui détermine la signature de la méthode à appeler statiquement, quitte à surprendre les gens qui font des tests tordus

[bulbo]

Ça n'est pas parce qu'une variable est masquée (non nommable -et encore pour protected elle est nommable-) qu'elle n'existe pas...

La c'est pas qu'elle est masquee du a une histoire de bloc ou autre, elle est carrement redefinie (ou devrait l'etre a mon avis)

Si B redefini la visibilite de la variable pour je ne sais quelle raison et qu'ensuite il traite la variable differemment, c'est cette variable qui doit etre toujours utilisee. Imagine les effets de bord sinon. Dans mon exemple c'est juste une String ca prete pas a consequence mais imagine que cette variable soit une socket et que tu l'initialise dans B par ton implementation de Socket qui crypte le contenu.
Bah du coup suivant la declaration de la variable referencant l'objet B tu crypteras ou pas.

Par contre si tu ne redefinis pas la variable protected tu crypteras toujours.

Cela signifie donc qu'il n'y a pas de redefinition possible des variables mais seulement masquage pas efficace efficace au niveau memoire ce truc

C'est d'ailleurs ce qui se passe pour toutes les variables privées. Dans une sous-classe, tu ne peux pas les nommer, pourtant elles sont bien présentes dans ton instance sur le "heap" à l'exécution.

Les variables privees c'est un autre debat puisqu'elles ne sont pas visibles dans la classe fille mais peut-etre utilisee dans le code de la classe mere, elles doivent etre presente.

Mais si le developpeur dit explicitement je veux cette visibilite sur cette variable pour moi ca ne signifie cree moi une autre variable et melange le tout a loisir, on fait pas une mayonnaise bon sang.

Pour ce qui est du choix des methodes ce n'est pas ca qui me genait, mais plus le coup de la variable qui est une fois l'une, une fois l'autre.

Bulbo

[®om]

Tu ne peux pas overrider des variables...
Si tu veux n'avoir qu'une variable, bah tu n'en déclares qu'une !!

Car là tu en déclares 2 qui ont le même nom, et tu te pleins d'en avoir 2...

Code :

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

1
2
3
class A {
    protected int x;
}

Code :

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

1
2
3
4
5
class B extends A {
    public B() {
        x=5;
    }
}

[bulbo]

C'est bien ce que j'ai fini par comprendre a force de tester des trucs tordus

Je ne sais pas pourquoi mais dans ma tete j'heritais aussi des variables donc possibilites de redefinition.

Bon bah je me coucherai moins bete ce soir, par contre j'avais un petit creux alors la medaille en choco je me la suis deja envoyee desole

Et tu as une idee du pourquoi on ne redefinit pas les variables ? Ya un interet a ca ? A part faire gaspiller de la memoire aux developpeurs tordus dans mon genre ?

Bulbo

[®om]

Pourquoi tu voudrais redéfinir des variables?
Quel serait l'intérêt...?

[bulbo]

Pourquoi tu voudrais redéfinir des variables?
Quel serait l'intérêt...?

Bah changer la visibilite (final, protected -> public) ce genre de choses permises par le langage quoi ..

Maintenant que je sais ce que je sais, c'est quelque chose que je ne ferai jamais, et ca ferait bien d'etre interdit tant qu'a faire les effets sont vraiment pernicieux ...

Imagine un boolean appeller shouldEncrypt (a toi de deviner a quoi ca peut servir ).
Une classe herite de celle ci et declare shouldEncrypt final et le met toujours a true.

Tu veux pas crypter facile:

Code :

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

1
2
3
SuperClass test = new ChildClass();
test.setEncryption(false);
test.faitLeTrucAEncrypter();

Bon c'est un exemple bancal, mais ca donne une idee de l'incoherence que ca introduit.

Toutes les methodes non redefinies dans la classe fille utiliseront le shouldEncrypt de la classe mere (qui a ete mis a false), les autres utiliseront celui de la classe fille

Bulbo

[bulbo]

Tient et comme j'aime pas les exemples bancals (banco ?) En voici un tres parlant et pas tordu la methode whatsyourRobotname ayant ete rajoute juste histoire de montrer ce qu'aurait du etre le nom dans un monde parfait

L'approche du developpeur de Robot est bonne, seulement voila, il ne peut pas deviner quel usage est fait de name dans le code de Human.

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
package dummy;
 
public class Human
{
  protected String name;
 
  public Human()
  {
    name = "John Doe";
  }
 
  public Human(String aName)
  {
    name = aName;
  }
 
  public void whatsyourname()
  {
    System.out.println("Mon nom est " + name);
  }
}
 
 
package dummy;
 
public class Robot extends Human
{
  // Le nom d'un robot est juste la reference de sa classe et ne doit pas pouvoir changer
  final protected String name = this.toString();
 
  public Robot()
  {
  }
 
  public void whatsyourRobotname()
  {
    System.out.println("Mon nom est " + name);
  }
 
  public static void main(String args[])
  {
    Robot robby = new Robot();
    robby.whatsyourname();
    robby.whatsyourRobotname();
  }
 
}

Et pour ceux qui diront que je suis fan d'Azimov et de serie avec Dominic Purcell et bah ils auront raison

Bulbo

[®om]

Je ne comprends pas tes exemples (ce que tu veux montrer). Et pourquoi tu veux absolument mettre dans une sous-classe un attribut qui porte le même nom?

Pour changer de nom dans une sous-classe, c'est une méthode getName() qu'il faudrait overrider, pas un attribut... Ou alors affecter cet attribut par une méthode/constructeur de la superclasse...

[bulbo]

Bon je sais que mon precedent post ne sonnait pas comme une question alors en voici une:

Avec l'exemple Human/Robot juste au dessus a l'appui pensez vous que la gestion des variables d'instances (cachees au lieu d'etre redefinie) est une bonne chose ou pitetre que Sun devrait revoir leur copie ?

Bon pour satisfaire tout le monde je rajoute un troisieme possibilite: ton exemple il est tout pourri et je refuse toute discussion serieuse un vendredi

Bulbo

[bulbo]

Je ne comprends pas tes exemples (ce que tu veux montrer). Et pourquoi tu veux absolument mettre dans une sous-classe un attribut qui porte le même nom?

Pourquoi pas, le langage l'autorise bien non ?

Pour la petite histoire je voulais expliquer par un petit exemple l'histoire de la resolution des methodes (compilation time et runtime) a un collegue et par le truchement d'un copier/coller je me suis retrouve a redefinir la variable protected et a avoir un comportement totalement bizarre.

Pour changer de nom dans une sous-classe, c'est une méthode getName() qu'il faudrait overrider, pas un attribut... Ou alors affecter cet attribut par une méthode/constructeur de la superclasse...

Je suis bien d'accord mais ce n'est pas une discussion sur le design d'application mais sur le comportement du langage.

D'ou la question: mais pourquoi donc que c'est fait comme ca ?

N'est ce pas dangereux et ne faudrait-il pas que ca soit fait autrement ?

Et concernant mon exemple Human/Robot tu trouves que j'ai ecrit n'importe quoi ? Et que ce genre de chose ne serait jamais faite par un developpeur meme moyen ?

Bulbo

[®om]

Une fois que tu sais que les variables ne sont pas redéfinies, mais que c'est bien une nouvelle variable que tu déclares, il n'y a pas de problème...

C'est comme quand tu as une variable locale du même nom qu'un attribut... c'est le même nom, mais c'est 2 variables différentes...

[bulbo]

C'est comme quand tu as une variable locale du même nom qu'un attribut... c'est le même nom, mais c'est 2 variables différentes...

Ce qui amene les gens a ecrire systematiquement this.toto = toto dans des setters.

Mais la c'est un probleme moindre, car le scope de la nouvelle variable est aisement identifiable dans le code, avec l'heritage le fait que cela soit l'une ou l'autre qui soit utilise depend uniquement de la variable referencant l'objet, sans compter que cela affecte aussi le code de la super classe donc peut-etre non disponible au developpeur.

On introduit la le concept de fuzzy programmation. Le developpeur peut faire passer tout les tests sur sa classe sans probleme et le premier developpeur qui aura le malheur de l'utiliser depuis une variable du type de la classe mere ne comprendra plus rien.
Si le langage permet la visibilite des variables de la classe mere, il doit a mon sens aussi s'assurer que cela se fasse de maniere sure et deterministe.

Toi je ne sais pas mais moi quand je code une classe je ne m'attends pas a ce que le type de la variable la referencant change son comportement interne.

Bulbo