Discussion :

[thomine]

Bonjour,

Je suis tombé sur 3 questions Java avec une petite classe d'exemple à la clé dont j'ai du mal à justifier théoriquement le pourquoi. J'aimerais avoir l'éclairage de quelques experts ! MERCI !

Exemple 1

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
public class TestHeritage {
	public static void main(String[] args) {
		Base2 b = new Derived2();
		System.out.println(b.getValue());
	}
}
 
class Base2 {
	int value = 0;
 
	Base2() {
		addValue();
	}
 
	void addValue() {
		value += 10;
	}
 
	int getValue() {
		return value;
	}
}
 
class Derived2 extends Base2 {
	Derived2() {
		addValue();
	}
 
	void addValue() {
		value += 20;
	}
}

Le "System.out.println(b.getValue());" affiche 40. J'ai du mal à m'expliquer pourquoi. Je pensais avoir 30. Je connais la règle de l'overridding, mais je pensais que dans le constructeur Base2, c'était le addValue de Base2 qui serait appelé vu que l'objet Derived2 n'est pas encore construit...

Exemple 2
L'exemple est le même avec les méthodes addValue en static :

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
public class TestHeritage2 {
	public static void main(String[] args) {
		Base3 b = new Derived3();
		System.out.println(b.getValue());
	}
}
 
class Base3 {
	static int value = 0;
 
	Base3() {
		addValue();
	}
 
	static void addValue() {
		value += 10;
	}
 
	int getValue() {
		return value;
	}
}
 
class Derived3 extends Base3 {
	Derived3() {
		addValue();
	}
 
	static void addValue() {
		value += 20;
	}
}

Ici, le System.out.println(b.getValue()); affiche 30. Ce que je comprends mieux. La justification est-elle qu'il n'y a pas de polymorphisme avec des méthodes statiques ?

Exemple 3

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
public class TestHeritage3 {
	void print(Base4 b) {
		System.out.println(b.show());
	}
 
	void print(Derived4 d) {
		System.out.println(d.show());
	}
 
	public static void main(String[] args) {
		TestHeritage3 t = new TestHeritage3();
		Base4 b = new Derived4();
		t.print(b);
	}
}
 
class Base4 {
	String s = "Base";
 
	String show() {
		return s;
	}
}
 
class Derived4 extends Base4 {
	String s = "Derived";
}

Le t.print(b); affiche Base, bien que l'objet soit un Derived4. La méthode appelée est print(Base4), puisque la règle de l'overloading dit que la résolution de la méthode se fait à la compilation. La référence de b étant Base4, c'est cette méthode qui est appelée. Par contre, le comportement des attributs est apparemment différent du comportement des méthodes. Il n'y a pas de polymorphisme est c'est l'attribut s de Base4 qui est affiché et non l'attribut s de Derived4 (pourtant l'objet est Derived4). Je cherche une explication claire à ce phénomène.

Voilà, un grand merci à ceux qui s'auront m'apporter une réponse claire à ces propriétés du langage Java !

[fabszn]

Hello,

Dans ton premier cas, il te manque le super() pour faire reference à au constructeur de ta classe mere!
Et les methodes statiques sont des methodes de classes et non d'instances donc je pense qu'elles ne sont pas impacté par le polymorphisme..

J'espere que cela t'aidera , si tu as des questions n'hesites pas!!

[thomine]

Merci pour ta réponse.

Dans le premier cas, il ne manque pas de super() car de toute manière il est implicite (comme le public dans les interfaces). C'est vrai qu'on peut l'ajouter pour une meilleure compréhension de l'exemple...

Avis aux autres amateurs.

[fabszn]

Hello,

Complément de réponse, dans ton premier exemple tu utilises Base2 comme une interface..

Code :

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

1
2
 
Base2 b = new Derived2();

Donc l'implémentation que tu retrouves dans b est celle de derived2() ; qui surcharge le constructeur et les méthodes de Base2 dans faire réference à l'implémentation de base2, par l'intermédiaire du mot clef super.

Je ne sais pas si je suis très clair... :

[BizuR]

avec TestHeritage :

Code :

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

1
2
3
4
5
6
7
8
9
const base : 0
add derived : 0
add derived fin : 20
const base fin : 20
const derived : 20
add derived : 20
add derived fin : 40
const derived fin : 40
40

avec TestHeritage2 :

Code :

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

1
2
3
4
5
6
7
8
9
const base : 0
add base : 0
add base fin : 10
const base fin : 10
const derived : 10
add derived : 10
add derived fi: 30
const derived fin : 30
30

avec TestHeritage3 :

Code :

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

1
2
print base4
Base

voila les résultat avec affichage ... comme tu le dis, c'est plutot étrange ...
Pour ma part, je savais que lors d'une instanciation, on instanciait chacun des parents avant la classe ... mais je ne pensais pas que l'on conserverait la méthode de la fille chez les parents ...
Par contre, la aussi, je ne vois pas trop pourquoi lors d'un appel pour static ... cette règle déroge du coup ...

Quant au dernier test ... j'aurai bien pensé à l'affichage de Base ... mais je pensais que l'objet passerai tout de même dans la méthode Derived4 ... je veux également bien une réponse à ce sujet sur l'explication des mécanismes d'héritage en java

[Deadpool]

Bonjour!

Pour l'exemple1:

L'instruction:

Code :

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

1
2
 
Base2 b = new Derived2();

entraîne les opérations suivantes:

1/ Appel du constructeur de Derived2 (par new Derived2()):
2/ L'appel de ce constructeur entraîne un appel au constructeur de Base2 (super() implicite)
3/ Dans le constructeur de Base2 tu à l'instruction addValue() => addValue de Derived2 est appelé (polymorphisme, l'objet construit est de type Derived2)
4/Dans la méthode addValue de Derived2 tu as l'instruction value += 20; donc on ajoute 20 à value qui vaut maintenant 20. L'appel à addValue de Derived2 se termine
5/On revient dans le constructeur de Base2, plus d'autre instruction => l'appel se termine
6/On revient dans le constructeur de Derived2, l'instruction suivante est addValue() => appel de addValue de Derived2
7/Dans la méthode addValue de Derived2 tu as l'instruction value += 20; donc on ajoute 20 à value qui vaut maintenant 40. L'appel à addValue de Derived2 se termine
8/On revient dans le constructeur de Derived2, plus d'autre instruction => appel au constructeur de Derived2 se termine

Csq: l'ojet est construit, value vaut bien 40. CQFD

Je regarde pour les autres...

Edit: J'espère que je suis clair...

[Deadpool]

Pour l'exemple2:

L'instruction:

Code :

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

Base3 b = new Derived3();

entraîne les opérations suivantes:

1/ Appel du constructeur de Derived3 (par new Derived3()):
2/ L'appel de ce constructeur entraîne un appel au constructeur de Base3 (toujours le super() implicite)
3/ Dans le constructeur de Base3 tu à l'instruction addValue() mais c'est une méthode statique. Qui dit static dit pas de référence this ou super donc comme tu l'as dit pas pas de polymorphisme possible => appel à addValue de Base3
4/Dans la méthode addValue de Base3 tu as l'instruction value += 10; donc on ajoute 10 à value qui vaut maintenant 10. L'appel à addValue de Base3 se termine
5/On revient dans le constructeur de Base3, plus d'autre instruction => l'appel se termine
6/On revient dans le constructeur de Derived3, l'instruction suivante est addValue() => appel de addValue de Derived3
7/Dans la méthode addValue de Derived3 tu as l'instruction value += 20; donc on ajoute 20 à value qui vaut maintenant 30. L'appel à addValue de Derived3 se termine
8/On revient dans le constructeur de Derived3, plus d'autre instruction => appel au constructeur de Derived3 se termine

Csq: l'ojet est construit, value vaut bien 30.

[thomine]

C'est cool, je vois que la discussion s'anime est intéresse des gens.

Pour l'exemple 1, comme le dit Descent, c'est le polymorphise qui est utilisé :

3/ Dans le constructeur de Base2 tu à l'instruction addValue() => addValue de Derived2 est appelé (polymorphisme, l'objet construit est de type Derived2)

Mais c'est vrai que dans ce cas précis (appel d'une méthode dans le constructeur de la superclasse !!!), je ne pensais pas que cette règle marchait.

En tout cas, merci des précisions, ça conforte les justifications que j'essaie de me faire.

[Deadpool]

Par contre l'exemple 3 me pose des problèmes!

[thomine]

Ben oui, pour l'exemple 3, si on a dans la tête le polymorphisme et qu'on l'applique (comme pour l'exemple 1), ben ça colle plus ! C'est pour ça que j'évoque le fait qu'il n'y a pas de polymorphisme pour les attributs. Mais j'attends une confirmation d'un membre avisé !

[@ldehan]

Par contre l'exemple 3 me pose des problèmes!

ah bah non pas drole, je suis d'accord pour les 2 premiers et j'attendais le 3eme parce que la je comprends pas.

parce que meme si c'est print(Base4 b) qui est appelé je ne comprends pas pourquoi le show() irait chercher la string s de Base4 et pas celle de Derived4 s'aggissant d'un membre d'instance

[Deadpool]

J'ai fait un test, en faisant :

Code :

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

1
2
3
 
Base4 b = new Derived4();
System.out.println(b.s);

Ca affiche "Base"

[@ldehan]

est-ce que ca sous-entendrait un probleme de polymorphisme avec les attributs ? ?

Je trouve quand même étrange que la règle soit différente selon le type de membre !

[thomine]

Ca a peut-être été conçu comme ça. Le polymorphisme n'est pas une notion qui s'applique aux attributs...

[Deadpool]

Autre point intéressant, en modifiant le code pour surcharger la méthode show dans Derived4 :

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
 
public class TestHeritage3 { 
   void print(Base4 b) { 
      System.out.println(b.show()); 
   } 
 
   void print(Derived4 d) { 
      System.out.println(d.show()); 
   } 
 
   public static void main(String[] args) { 
      TestHeritage3 t = new TestHeritage3(); 
      Base4 b = new Derived4(); 
      t.print(b); 
   } 
} 
 
class Base4 { 
   String s = "Base"; 
 
   String show() { 
      return s; 
   } 
} 
 
class Derived4 extends Base4 { 
   String s = "Derived"; 
   String show() { 
      return s; 
   } 
}

Ca affiche "Derived" bien que System.out.println(b.s) affiche toujours "Base".

[@ldehan]

Autre point intéressant, en modifiant le code pour surcharger la méthode show dans Derived4 :

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
 
public class TestHeritage3 { 
   void print(Base4 b) { 
      System.out.println(b.show()); 
   } 
 
   void print(Derived4 d) { 
      System.out.println(d.show()); 
   } 
 
   public static void main(String[] args) { 
      TestHeritage3 t = new TestHeritage3(); 
      Base4 b = new Derived4(); 
      t.print(b); 
   } 
} 
 
class Base4 { 
   String s = "Base"; 
 
   String show() { 
      return s; 
   } 
} 
 
class Derived4 extends Base4 { 
   String s = "Derived"; 
   String show() { 
      return s; 
   } 
}

Ca affiche "Derived" bien que System.out.println(b.s) affiche toujours "Base".

ce qui sous-entendrait que les appels d'attributs au sein d'une méthode ne peuvent pas descendre l'héritage.

Ce sui parait pas si illogique que ca en fait. Sinon ce cas poserait probleme :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class Base {
   String s = "Base";
 
   String show() {
      return s;
   }
}
 
class Derived extends Base {
   int s = 4;
}

[RanDomX]

Meme si base et Derived sont "assignement compatible", les signatures de print sont différentes.


Comme tu passes un Base, et que la classe trouve une signature de print qui corresponds, alors il applique celle qui colle le plus. Si il n'en trouve pas, il va chercher une signature compatible par assignement.

Mais par defaut il cherche le type de l'objet passé (le type de la variable) et pas forcement le type de l'objet concret.

Essais en castant en Derived ton objet b.

@+

Lionel

[thomine]

C'est vrai. Ton dernier exemple est pas mal et apporte une partie de l'explication.

Bon, y'aurait pas un Java Guru dans les parages pour nous clarifier tout ça ! En tout cas on voir qu'à partir d'une pauvre classe d'exemple, on est amené à se poser pas mal de questions !

[adiGuba]

Salut,


Les méthodes non-static sont des méthodes virtuelles. C'est à dire que la JVM recherchera la bonne méthode a appeller à l'exécution seulement. Plus de détail dans les specs : invokevirtual
Cela permet la redéfinition des méthodes dans les classes filles. L'exécution de l'une ou de l'autre dépend du type réel de l'instance de la classe...


A l'inverse, les méthodes statiques et les attributs de classes ne peuvent pas être redéfini. Il n'y a aucun lien entre l'attribut "s" de Base4 et l'attribut "s" de Derived4, si ce n'est qu'ils ont le même nom. La résolution de ces éléments se fait donc généralement à la compilation. Ainsi la méthode show() renverra toujours le "s" de Base4 et aucun autre...

On peut très bien void que la classe Derived4 possède bien deux attribut "s" (le sien plus celui hérité de Base4) avec le code suivant (il faut caster l'objet pour accéder à celui de la classe parente) :

Code :

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

1
2
3
4
Derived4 d = new Derived4();
 
System.out.println( d.s ); // Affiche "Derived"
System.out.println( ((Base4)d).s ); // Affiche "Base"

a++

PS : bien sûr il est plutôt déconseillé d'utiliser les mêmes noms pour les attributs et les méthodes statiques...

[thomine]

Ah ben voilà ! Le messie a parlé ! Voilà la vraie réponse que j'attendais. Merci à adiGuba pour cet éclairage.

Je vais donc résoudre ce sujet qui a motivé pas mal de gens (et tant mieux !).
Longue vie à developpez.com !