Initialisation d'un objet

Bonjour,

voici un petit test, s'il vous plait essayer de répondre sans compiler
et exécuter le code. Voici Deux classes (ci-dessous), la question est:
Lorsque j'execute B, qu'est ce que je vois dans la console ?

D'autre part j'aimerais savoir s'il ya une solution à mon problème:
est-ce que quelqu'un sait ce qu'il faut faire pour avoir le
fonctionnement attendu ? selon les specs java de sun dans l'ordre:
- initialisation des variables
- exécution des blocs d'initialisation
- appel du constructeur

merci pour votre participation
public class A
{
public A()
{
super();
System.out.println(this);
}
}


public class B extends A
{
private String toto = "coucou1";
{
toto = "coucou2";
}
public B()
{
super();
toto = "coucou3";
}
public String toString()
{
return toto;
}
public static void main(String[] args)
{
new B();
}
}
a froid coucou2 sans compilation

new b ->super donc a a->(super ???)-> System.out.println(this);
this=toString ->toto =coucou2

remy

Bonjour,

voici un petit test, s'il vous plait essayer de répondre sans compiler
et exécuter le code. Voici Deux classes (ci-dessous), la question est:
Lorsque j'execute B, qu'est ce que je vois dans la console ?

D'autre part j'aimerais savoir s'il ya une solution à mon problème:
est-ce que quelqu'un sait ce qu'il faut faire pour avoir le
fonctionnement attendu ? selon les specs java de sun dans l'ordre:
- initialisation des variables
- exécution des blocs d'initialisation
- appel du constructeur

merci pour votre participation
public class A
{
public A()
{
super();
System.out.println(this);
}
}


public class B extends A
{
private String toto = "coucou1";
{
toto = "coucou2";
}
public B()
{
super();
toto = "coucou3";
}
public String toString()
{
return toto;
}
public static void main(String[] args)
{
new B();
}
}
a froid coucou2 sans compilation

new b ->super donc a a->(super ???)-> System.out.println(this);
this=toString ->toto =coucou2

remy
je dirais coucou1

parce que la valeur coucou2 donnée à toto ne se fait qu'une fois le
constructeur de A terminé. Or, c'est dans le constructeur de A qu'on
fait afficher coucou1.

Autre possibilité, il affiche quelquechose du genre "Instance de la
classe A" parce que toString() n'est pas encore enregistré

Presque ! ;-)
bonne logique. Maintenant tu peux compiler (moi j'ai compiler avec la
vm 6 de sun) et regarder la console. Tu verras c'est assez étonnant,
je ne comprends toujours pas.

J'attends encore la bonne réponse.

merci Rémy


On 6 déc, 14:33, remy <r...@fctpas.fr> wrote:

Bonjour,

voici un petit test, s'il vous plait essayer de répondre sans compiler
et exécuter le code. Voici Deux classes (ci-dessous), la question est:
Lorsque j'execute B, qu'est ce que je vois dans la console ?

D'autre part j'aimerais savoir s'il ya une solution à mon problème:
est-ce que quelqu'un sait ce qu'il faut faire pour avoir le
fonctionnement attendu ? selon les specs java de sun dans l'ordre:
- initialisation des variables
- exécution des blocs d'initialisation
- appel du constructeur

merci pour votre participation
public class A
{
public A()
{
super();
System.out.println(this);
}
}

public class B extends A
{
private String toto = "coucou1";
{
toto = "coucou2";
}
public B()
{
super();
toto = "coucou3";
}
public String toString()
{
return toto;
}
public static void main(String[] args)
{
new B();
}
}

a froid coucou2 sans compilation

new b ->super donc a a->(super ???)-> System.out.println(this);
this=toString ->toto =coucou2

remy

je dirais coucou1

parce que la valeur coucou2 donnée à toto ne se fait qu'une fois le
constructeur de A terminé. Or, c'est dans le constructeur de A qu'on
fait afficher coucou1.

Autre possibilité, il affiche quelquechose du genre "Instance de la
classe A" parce que toString() n'est pas encore enregistré

ATTENTION SPOILER












etonnement, la String toto existe au moment de l'appel à toString() mais
n'a pas encore été initialisée. Par contre, si on déclare toto en tant
que final et qu'on retire les 2 autres assignations (sinon ça compile
pas) on a bien coucou1 qui s'affiche.


maintenant, selon quelle logique les méthodes virtuelles sont insérées
avant l'execution du constructeur (de B), je vois pas trop...
moralité, éviter d'appeler des méthodes surchargées dans les constructeurs

Merci Aris pour cette réponse commenté,

c'est vrai qu'il faut éviter d'appeler des méthodes surchargées dans
un constructeur, mais c'est dommage. L'exécution de code dans un
constructeur ne devrait servir qu'à initialiser des variables.

Voici une analyse de Jean-Charles sur le sujet :

public class A
{
public A()
{
super();
System.out.println(this);
}

}

public class B extends A
{

// "this is titi" est une constante de compilation, dans le code
compilé seule la valeur reste.
private final String titi = "this is titi";

// ceci une référence instanciée au moment de la création de la
classe
private final Integer tutu = new Integer(5);

// cette chaine n'est pas constante donc elle est initialisée au
moment de la création de la classe
private String toto = "coucou1";
{
toto = "coucou2";
}
public B()
{
// la méthode super est appelée avant que le nouvel objet B
soit initialisé
super();
toto = "coucou3";
}
public String toString()
{
return "Toto: " + toto + ", Tutu: " + tutu + ", Titi: " +
titi;
}
public static void main(String[] args)
{
new B();
// dans la console on obtient: "Toto: null, Tutu: null,
Titi: this is titi"
}
}



merci pour votre réactivité ;-)

On 6 déc, 15:18, Aris <a...@badcode.be> wrote:

je dirais coucou1

parce que la valeur coucou2 donnée à toto ne se fait qu'une fois le
constructeur de A terminé. Or, c'est dans le constructeur de A qu'on
fait afficher coucou1.

Autre possibilité, il affiche quelquechose du genre "Instance de la
classe A" parce que toString() n'est pas encore enregistré

ATTENTION SPOILER

etonnement, la String toto existe au moment de l'appel à toString() mais
n'a pas encore été initialisée. Par contre, si on déclare toto en tant
que final et qu'on retire les 2 autres assignations (sinon ça compile
pas) on a bien coucou1 qui s'affiche.

maintenant, selon quelle logique les méthodes virtuelles sont inséré es
avant l'execution du constructeur (de B), je vois pas trop...
moralité, éviter d'appeler des méthodes surchargées dans les const ructeurs

Bonjour,

voici un petit test, s'il vous plait essayer de répondre sans compiler
et exécuter le code. Voici Deux classes (ci-dessous), la question est:
Lorsque j'execute B, qu'est ce que je vois dans la console ?

D'autre part j'aimerais savoir s'il ya une solution à mon problème:
est-ce que quelqu'un sait ce qu'il faut faire pour avoir le
fonctionnement attendu ? selon les specs java de sun dans l'ordre:
- initialisation des variables
- exécution des blocs d'initialisation
- appel du constructeur

merci pour votre participation
public class A
{
public A()
{
super();
System.out.println(this);
}
}


public class B extends A
{
private String toto = "coucou1";
{
toto = "coucou2";
}
public B()
{
super();
toto = "coucou3";
}
public String toString()
{
return toto;
}
public static void main(String[] args)
{
new B();
}
}
a froid coucou2 sans compilation

new b ->super donc a a->(super ???)-> System.out.println(this);
this=toString ->toto =coucou2

remy
Une super classe ne peut pas connaître les méthodes d'une sous classe. Ni ses

variables.

--
Christian Laborde
True E-mail : remove dash and no spam
Rte de la Conversion, 20
CH 1095 Lutry
Suisse

Bonjour,

voici un petit test, s'il vous plait essayer de répondre sans compiler
et exécuter le code. Voici Deux classes (ci-dessous), la question est:
Lorsque j'execute B, qu'est ce que je vois dans la console ?

D'autre part j'aimerais savoir s'il ya une solution à mon problème:
est-ce que quelqu'un sait ce qu'il faut faire pour avoir le
fonctionnement attendu ? selon les specs java de sun dans l'ordre:
- initialisation des variables
- exécution des blocs d'initialisation
- appel du constructeur

merci pour votre participation
public class A
{
public A()
{
super();
System.out.println(this);
}
}


public class B extends A
{
private String toto = "coucou1";
{
toto = "coucou2";
}
public B()
{
super();
toto = "coucou3";
}
public String toString()
{
return toto;
}
public static void main(String[] args)
{
new B();
}
}
a froid coucou2 sans compilation

new b ->super donc a a->(super ???)-> System.out.println(this);
this=toString ->toto =coucou2

remy
Une super classe ne peut pas connaître les méthodes d'une sous classe.

Ni ses variables.

En fait ici B reimplémente une méthode d'une superclasse de A :

Object::toString().
ce qui est étonnant, c'est que le constructeur de A ait accès au
toString() de B et non pas au toString de Object

En fait ici B reimplémente une méthode d'une superclasse de A :
Object::toString().
ce qui est étonnant, c'est que le constructeur de A ait accès au
toString() de B et non pas au toString de Object

chez moi j'ai un null
et comme je me suis fait la même remarque en gros

public class B
{

public static void main(String[] args)
{
ABCD a=new ABCD();
a.fctA((A)a);
a.fctA((AB)a);
a.fctA((ABC)a);
a.fctA((ABCD)a);

A a0=new ABCD();
a0.fctA((A)a0);
a0.fctA((AB)a0);
a0.fctA((ABC)a0);
a0.fctA((ABCD)a0);


}
}

class A
{

public void fctA( A a)
{
System.out.println("A");
}
}
class AB extends A
{

public void fctA( AB a)
{
System.out.println("AB");
}
}
class ABC extends AB
{

public void fctA( ABC a)
{
System.out.println("ABC");
}
}
class ABCD extends ABC
{

public void fctA( ABCD a)
{
System.out.println("ABCD");
}
}

sortie console

A
AB
ABC
ABCD
A
A
A
A

et il me semble bien qu'à une époque j'avais bien mais je peux me planter

A
AB
ABC
ABCD
A
AB
ABC
ABCD

cela peut expliquer le pourquoi du comment ?

remy

j'ai comme un gros doute la
un seul fichier avec le code poster au dessus
javac B.java
java B
cela donne quoi ?

merci remy

j'ai comme un gros doute la
un seul fichier avec le code poster au dessus
javac B.java
java B
cela donne quoi ?

merci remy
Moi aussi j'ai null, ce qui me semble cohérent.

--
Christian Laborde
True E-mail : remove dash and no spam
Rte de la Conversion, 20
CH 1095 Lutry
Suisse