Discussion :

[grub_fr]

Bonjour a ts et ttes,

je suis sur la rédact° de tests unitaires et je decouvre eclipse.

Lors de la rédact° d'1 test (ce qui n'est pas le sujet ici),

j'ecris mon constructeur de maniere classique

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
 
public class Vehicule {
 
	private int id;
	private int count= 0;
	private String type;
	private int kilometrage;
	private String plaque;
 
	public Vehicule(String p_type, int p_kilometrage, String p_plaque) {
 
		this.type = p_type
		this.kilometrage = p_kilometrage;
		this.plaque = p_plaque;
 
		this.id = ++count;
 
	}
}

Ensuite j'utilise eclipse pr generer les getter / setter

et là Eclipse transforme mon constructeur de cette manière

Code :

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

1
2
3
4
5
6
7
8
9
10
 
public Vehicule(String p_type, int p_kilometrage, String p_plaque) {
 
		this.setType(p_type);
		this.setKilometrage(p_kilometrage);
		this.setPlaque(p_plaque);
 
		this.setId(setCount(getCount() + 1));
 
	}

Du coup, me je pose les questions:
Y'a t-il 1 syntaxe + efficace qu'1 autre?
Cela depend il du contexte?
Si oui, qd choisir telle syntaxe plutot que telle autre?

Merci bien pr les précisions.
grub

[professeur shadoko]

la deuxième suggestion peut être intéressante si tu fais des contrôles de validité lors d'un "set"... ça centralise ces contrôles.
sinon pas strictement nécessaire... mais ça ne coûte rien.

[gervais.b]

Le problème avec le version "corrigée" par Eclipse est qu'il va vous forcer à utiliser des setters pour toutes les affectations. Ca n'est pas un problème en soi surtout si, comme le dit professeur shadoko, vous faites de la validation dans les setters. Le vrai problème est si les setters sont public car ils exposent alors toute votre classe et peut-être même certains champs que vous voudriez garder privé.

[professeur shadoko]

Le vrai problème est si les setters sont public car ils exposent alors toute votre classe et peut-être même certains champs que vous voudriez garder privé.

oups j'avais oublié ça! Il est vrai qu'il est essentiel d'avoir des mutateurs non public pour maintenir l'encapsulation. (je peste assez contre ces générateurs qui les proposent systématiquement public! je n'ai pas Eclipse mais je suppose qu'il y a une option pour gérer ça)

[OButterlin]

J'utilise Eclipse depuis des décennies et il ne m'a jamais remplacé les affectations dans un constructeur comme indiqué dans l'exemple.
J'ai fait le test avec la classe Véhicule telle que décrite et là encore, pas de modification du constructeur.
Il doit donc y avoir eu une modification quelque part du mécanisme standard d'Eclipse.

De mon point de vue :

• la version initiale est la plus performante.
• utiliser le principe des setter si des contrôles (ou des affectations connexes) ont été codés.

Pour le tout petit détail, il manque un ; derrière l'affectation de type par p_type dans le constructeur initial...


Pour la remarque de gervais.b, un setter n'expose pas une classe pas plus que les propriétés qu'il pourrait utiliser dans son traitement... que voulais-tu dire ?

Je ne comprends pas la dernière remarque de professeur shadoko (j'ai du raté quelque chose).
Quel intérêt de mettre les setter private (protected encore ça peut se comprendre) ? Ils sont généralement public vu qu'ils servent à affecter une valeur à une propriété.
Si on ne veut pas que la valeur puisse changer (facilement), autant ne pas les définir...

Pour ce qui est de la "protection", dans tous les cas, c'est plus un vœu qu'une réalité en java. On peut toujours utiliser la "reflection" pour modifier directement la valeur d'une propriété (qu'elle ait ou non un setter) pour autant quelle ne soit pas "static final".

[professeur shadoko]

Je ne comprends pas la dernière remarque de professeur shadoko (j'ai du raté quelque chose).
Quel intérêt de mettre les setter private (protected encore ça peut se comprendre) ? Ils sont généralement public vu qu'ils servent à affecter une valeur à une propriété.
Si on ne veut pas que la valeur puisse changer (facilement), autant ne pas les définir...
.

oops.. remarque pertinente. Je me laisse emporter par ma haine des mutateurs publics systématiques.