Discussion :

[lvr]

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.

[thelvin]

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.

[lvr]

... 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 :

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

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 :

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

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"

[thelvin]

C'est quoi la solution ?

Celle qui fait le taf'.

Dans ton exemple, il y a le simple :

Code :

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

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 :

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

1
2
3
4
5
class B extends A {
  public B() {
    super(new PanelY());
  }
}

Une solution avec des factory serait-elle mieux ?

Ça peut dans des cas plus compliqués.

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

Pas plus que d'habitude.

[hwoarang]

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

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
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.

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 :

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
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.

[lvr]

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.

[thelvin]

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.