"overridable method called in constructor" : où est le problème ?

Bonjour,

NetBeans me met un wanring chaque fois que j'utilise une méthode non finale dans un constructeur.
Où est le problème ?
Au contraire, je trouve ça très pratique.
Cela permet à des sous-classes de s'initier de manière customisée.

Citation:

---

Envoyé par lvr

Cela permet à des sous-classes de s'initier de manière customisée.

---

... Et cela avant que le constructeur de leur classe mère se soit terminé, ce qui est contraire à l'encapsulation et donc un appel aux bugs.

Citation:

---

Envoyé par thelvin

... Et cela avant que le constructeur de leur classe mère se soit terminé, ce qui est contraire à l'encapsulation et donc un appel aux bugs.

---

C'est quoi la solution ?

Exemple, j'ai une application Swing dont son initialisation j'ai écris

Code:

---

1 2 3 4 5 6 7 8 9 10

class A extends JFrame { final JPanel; public A() { JPanel panel=createPanel(); }   JPanel createPanel() { return new PanelX(); } }

---

Je veux une version spéciale de cette application dans laquelle j'aurai un panneau légèrement revu.
Je crée donc donc une sous classe de mon

Code:

---

1 2 3 4 5 6 7 8 9 10

class B extends A { public B() { super() }   @Overide JPanel createPanel() { return new PanelY(); } }

---

Une solution avec des factory serait-elle mieux ? Sauf que cela ne fonctionne pas avec les attributs "final"

Citation:

---

Envoyé par lvr

C'est quoi la solution ?

---

Celle qui fait le taf'.

Dans ton exemple, il y a le simple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

class A extends JFrame { final JPanel;   protected A(Jpanel panel) { this.panel = panel; }   public A() { this(new PanelX()); }     }

---

Code:

---

1 2 3 4 5

class B extends A { public B() { super(new PanelY()); } }

---

Citation:

---

Envoyé par lvr

Une solution avec des factory serait-elle mieux ?

---

Ça peut dans des cas plus compliqués.

Citation:

---

Envoyé par lvr

Sauf que cela ne fonctionne pas avec les attributs "final"

---

Pas plus que d'habitude.

Deja, commencons par le probleme. Le cas suivant, par exemple, ne marcherait pas :

Citation:

---

Envoyé par lvr

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

class A extends JFrame { final JPanel; public A() { JPanel panel=createPanel(); }   JPanel createPanel() { return new PanelX(); } }   class B extends A { JPanel monPan = new PanelB(); public B() { super() }   @Overide JPanel createPanel() { return monPanel; } }

---

---

Ca ne saute pas aux yeux mais le probleme, c'est que les variables de classes de B sont initialisées apres celles de A. Donc au moment de l'appel de createPanel dans le constructeur du pere de B, monPanel sera null. Dans ce cas, ca va générer une NullPointerException donc c'est facilement compréhensible mais dans le cas d'une modification de variable utilisée par le pere ou quelque chose de plus complexe, ca risque d'etre moins trivial a debugger.

Citation:

---

Envoyé par lvr

Une solution avec des factory serait-elle mieux ? Sauf que cela ne fonctionne pas avec les attributs "final"

---

L'attribut n'a pas besoin d'etre "final" dans le cas d'une factory. Si l'objectif de dériver la classe est seulement de creer des panels différents, oui, ca peut etre une solution. Pour un probleme qui ressemble, j'avais choisi la solution d'avoir un constructeur tres simple mais d'imposer l'appel à une fonction "build" qui fait en gros ce que fait ton constructeur. Ca donne quelque chose comme ca :

Code:

---

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

class A extends JFrame { final JPanel; public A() { }   public void build() { JPanel panel=createPanel(); }   JPanel createPanel() { return new PanelX(); } }   class B extends A { JPanel monPan = new PanelB(); public B() { super() }   @Overide JPanel createPanel() { return monPanel; } }

---

Et la, ca marche.

Je vois où le problème... Je crois que je vais abandonner cette mauvaise "bonne" pratique... Reste à voir comment au cas par cas.

J'hésitais aussi aux méthodes de type "build()". Mais ça rend plus compliqué le travail avec des GUI builder comme celui de Netbeans...
Quant aux paramètres, ça marche s'il y en a 1 ou 2 après ça devient compliqué...

Merci pour les pistes.

Citation:

---

Envoyé par lvr

Quant aux paramètres, ça marche s'il y en a 1 ou 2 après ça devient compliqué...

---

Un paramètre, qui est une classe qui contient les autres paramètres.

Si nécessaire, ce paramètre peut carrément être une factory ou un builder.

Personellement, dans les applications plus complexes, quand ça s'y prête, j'utilise cette solution

Code:

---

1 2 3 4 5 6

@Configurable public class X { @PostConstruct protected void init(){ } }

---

Mais ça ne marche que si on a intégré spring à l'application ;)

Citation:

---

Envoyé par tchize_

Mais ça ne marche que si on a intégré spring à l'application ;)

---

Ce serait beau. Mais je ne connais Spring que de nom... A investiguer pour la prochaine application.