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.

[grub_fr]

Bonjour a vous,

Je pose les bases avt de...

A la lecture de mon post, vs avez dû comprendre
- que je debute en Java (en prog, je suis 1 amateur éclairé a la bougie)
- que je debute sous eclipse.

professeur shadoko dit:

la deuxième suggestion peut être intéressante si tu fais des contrôles de validité lors d'un "set"

Je comprends que vos fameux controles de validité se redigent ds la classe a tester, a la declaration des setter et non pas ds la classe de test (qui est le test unitaire)

exemple:

Code :

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

1
2
3
4
 
public void setId_autocar(int id_autocar) {
		this.id_autocar = id_autocar;
	}

C'est ici, j'ajoute les controles de validité?
Avec des condit° if, else, switch (et sans doute d'autres que je ne connais pas)?

professeur shadoko rajoute:

ça centralise ces contrôles.

Ca me semble plutôt une bonne chose de centraliser.

OButterlin dit:

la version initiale est la plus performante.

Ok, je prends note pr la suite, car etant débutant, la rapidité passe pr le moment au second plan (+ la simplcité de ce que j'ecris...)

OButterlin rajoute

Pour ce qui est de la "protection", dans tous les cas, c'est plus un vœu qu'une réalité en java

Il me semble que j'en prends cse petit a petit.

La recherche sur la "reflection" (faute d'ortographe volontaire ou pas?) se fera un peu plus tard.

Je laisse le post ouvert encore un moment, histoire de voir si je dois creuser des idées.

Je m'en vais de ce pas faire un autre post que que vous (les intervenants forum, pas vs 3 spécifiquement) puissiez me dire ce que vs en pensez.

Merci pr vos réponses.
grub

[OButterlin]

Effectivement, en français, on écrirait réflexion, mais là, on parle d'une fonctionnalité java.

Reflection is a feature in the Java programming language. It allows an executing Java program to examine or "introspect" upon itself

Cette fonctionnalité permet d'explorer des classes, lister les méthodes, extraire des valeurs ou changer les valeurs de propriétés.
C'est surtout utile dans la conception d'outils.
Ci-dessous un exemple de modification de la propriété "id" de ta classe Vehicule

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
...
        Vehicule v = new Vehicule("VL", 160000, "116 LX 68");
        System.out.println("id = " + v.getId());
 
        try
        {
            Field field = v.getClass().getDeclaredField("id");
            field.setAccessible(true);
            field.set(v, 4);
            System.out.println("id = " + v.getId());
        }
        catch (Exception e)
        {
            e.printStackTrace();
        }
...

[grub_fr]

re,

ok, je clos le post.

Merci pr vos éclaircissements et pour l'explication de ce qu'est la reflection.

Bonne journée a vous,
grub