Discussion :

[sc_wizard29]

Salut les gens,

Voici un petit bout de code tout simple :

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
 
public abstract class AbstractClass {
    protected AbstractClass() { init(); }
    protected void init() { }
}
 
public class ClassImpl extends AbstractClass {
    private String var;
 
    public ClassImpl(String var) { this.var = var; }
 
    protected void init() {
        super.init();
        System.out.println("var=[" + var + "]");
    }
}

Si je fais "new ClassImpl("coucou")", ça affiche "var=[null]".

"Logique" quand on y réfléchit, mais pas génial quand on veut avoir deux méthodes init() afin de dissocier l'initialisation de la classe abstraite et l'initialisation de la classe concrète.

En fait, j'aimerais éviter d'appeler explicitement init() dans le constructeur de ClassImpl...quel est selon-vous la meilleure façon de résoudre ce problème ?

PS : non, je ne souhaite pas supprimer les méthodes init() et mettre le code directement dans le constructeur.

Merki !

[adiGuba]

Salut,

PS : non, je ne souhaite pas supprimer les méthodes init() et mettre le code directement dans le constructeur.

C'est pourtant la meilleure solution...


a++

[sc_wizard29]

Salut,

C'est pourtant la meilleure solution...


a++

Certes, sauf que dans mon code, j'ai en réalité plusieurs méthodes nommées initXX(), initYY() & initZZ() qui sont chacune relativement longues.

Du coup, avoir le constructeur de la classe abstraite qui appelle ces 3 méthodes à la suite est plus lisible qu'avoir un constructeur qui fait 50 lignes.

[thelvin]

Ce qui est important c'est que les classes filles ne redéfinissent pas ces méthodes. Autrement dit, de "faire comme si" elles étaient entièrement dans le constructeur. Il suffit de les nommer autrement d'une classe à l'autre, ou de les faire private.

Bien sûr, ça signifie que chaque constructeur doit appeler sa liste de méthodes à appeler.

Edit : Ah, et bien sûr il ne faut pas de déclaration abstraite de ces méthodes, puisqu'elles ne doivent pas être redéfinies.

[Logan Mauzaize]

Rends les privées Ca reviendra au même que de copier/coller le code.
Tu peux également te passer de méthodes en faisant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
public class FooBar {
  {
     // initXXX()
  }
  {
    // initYYY()
  }
  {
    // initZZZ()
  }
}

Pour ton problème il n'y a pas de solution, tu essayes de violer un paradigme objet (initialiser la classe fille durant l'initialisation de la classe mère).

Dans Log4j ils ont décidés que la méthode "init" ne serait appelé qu'après construction et initialisation de l'objet.

Autre solution passé en paramètre au constructeur de la classe mère les paramètres du constructeur de la classe fille qui seront ensuite passé à la méthode init.

[adiGuba]

Certes, sauf que dans mon code, j'ai en réalité plusieurs méthodes nommées initXX(), initYY() & initZZ() qui sont chacune relativement longues.

Dans ce cas il est préférable de passer ces méthodes en private et de les appeler dans le constructeur de la classe en question.

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
public abstract class AbstractClass {
    protected AbstractClass() { init(); }
    private void init() { }
}
 
public class ClassImpl extends AbstractClass {
    private String var;
 
    public ClassImpl(String var) {
        this.var = var;
        init();
    }
 
    private void init() {
        System.out.println("var=[" + var + "]");
    }
}

Un constructeur ne devrait pas utiliser ses méthodes virtuelles, car lors de son exécution l'objet n'est pas forcément complètement initialisé...


a++

[sc_wizard29]

Merci à tous pour vos réponses,

Il semble effectivement plus judicieux d'appeler explicitement la méthode init() dans chacun des constructeurs.

A la base je cherchais une solution pour "éviter" de le faire, mais force est de constater que ça ne marche pas ;-)