Discussion :

[ChPr]

Bonsoir à toutes et à tous,

J'ai créé une classe (j'espère avoir respecté les conventions d'écriture ) et tout ce qui suit compile sans problème :

Code :

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

1
2
3
4
5
6
7
public class PTS {
	public String nom;
	public String date;
	public String formerLgn() {
		return nom+date;
	}
}

J'instancie ma classe :

Code :

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

PTS mesRef = new PTS();

Lorsque de l'extérieur, j'écris :

Code :

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

String maDate = mesRef.date;

ça fonctionne.

Maintenant, si j'appelle la méthode de mon instance :

Code :

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

String maLigne = mesRef.formerLigne();

ça plante ???

Merci de votre aide.

Pierre

[Minicalion]

Salut ChPr,

tiens une classe avec des attributs public ça me dis vaguement quelque chose... lol En tous cas, je note un jolie effort sur les conventions de nommage c'est bien!!

En revanche, comme dirais certains, ça plante / ça marche pas, ça ne veut rien dire, même pour nous. Si on pouvais avoir le message d'erreur ça nous aiderais aussi.

En tous cas, je trouve bizarre la déclaration formerLgn(), et apres l'utilisation formerLigne(), ça ne viendrais pas de là par hasard??? Si c'est ça, il faut apprendre à utiliser l’auto complétion, c'est juste énorme.
Une fois qu'on y a goûté, on ne s'en passe plus!!!! (je me demande toujours pourquoi Word ne le fait pas ).

[nicroman]

Oui c'est "presque" respecté....

Par contre: PTS ... dans le nom de la classe veut dire que la classe s'appelle de trois nom "P" "T" et "S" on voit bien que ce n'est pas le cas. PeinardToutSeul ?

Ensuite... une variable membre ne devrait jamais être publique. Cela relève du principe en orienté-objet de découplage de l'interface (fonctions) et de l'implémentation (membres, corps des fonctions).

Et pour les fonctions, encore une fois, utiliser un verbe permet de rendre les choses plus claires. Par exemple:

Code java :

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 class PeinardToutSeul
{
    private String nom;
    private String date;
 
    // les "setters"
    public void setNom(String n) { this.nom = n; }
    public void setDate(Date d) { this.date = d; }
 
    // les "getters"
    public String getNom() { return this.nom; }
    public String getDate() { return this.date; }
 
    // les "getters composites" (Lgn ?)
    public String getFormerLogin() { return this.nom + this.date; }
}

Désolé pour l'utilisation de "this." mais c'est une convention que j'ai choisi personnellement pour me permettre de bien distinguer les variables "membres" et les autres. D'ailleurs il est possible de dire à eclipse que ne pas mettre le "this." est une erreur.
Il est à noter que normalement, les getters composites devraient utiliser les getters simples au lieu de directement accéder aux valeur des membres. Pourquoi ? pour permettre d'hériter par exemple de la classe, et avoir ainsi, un type de "PeinardToutSeul" ou date vaut toujours quelque chose de fixe... getDate() renverra cette valeur, setDate() enverra une exception... et on n'a pas besoin de changer les getters composites de la classe parente....

Revenons à nos moutons... Que se passe-t-il quand on execute le code:

Code :

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

PeinardToutSeul  pts = new PeinardToutSeul();

On instancie un nouvel objet de type "PeinardToutSeul", initialisé avec les valeurs par défaut (puisqu'il n'y a pas de constructeur). C'est à dire, tout à null (pts.date est null et pts.nom est null).

Code :

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

pts.getDate();

fonctionne, et renverra null (aucune date)

Code :

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

pts.getNom();

fonctionne aussi d'ailleurs, et renverra aussi null (aucun Nom)
Par contre:

Code :

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

pts.getFormerLogin();

va "crasher" avec un joli NullPointerException, parcequ'on utilise l'opérateur '+' entre une String (à gauche) et un objet (à droite). Le compilateur java étant bon avec nous il va gentillement transformer le code de getFormerLogin() en:

Code :

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

1
2
3
4
5
6
7
 
public String getFormerLogin()
{
    StringBuilder builder = new StringBuilder(this.name);
    builder.append(this.date);
    return builder.toString();
}

Hors, si on regarde la définition du constructeur de StringBuilder (à partir d'une String) il est écrit en toutes lettres:

Throws:
NullPointerException - if str is null

this.name est null ... donc le constructeur du StringBuilder envoit NullPointerException.... CQFD.

Comment résoude le problème ? Par exemple:

Code :

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

1
2
3
 
public String getFormerLogin() {
    return (this.name == null) ? null : ((this.date == null) ? this.name : this.name + this.date);

Bon... l'opérateur ternaire "? :" est un peu complexe à appréhender, mais ici cela se traduit en:

Code :

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

1
2
3
4
5
6
 
public String getFormerLogin() {
    if (this.name == null) return null;
    if (this.date == null) return this.name;
    return this.name + this.date;
}

[Minicalion]

Bon ok je m'incline, le "ça plante" à parlé à nicroman.

C'est dans ces moments là que je me dis que j'ai encore beaucoup de choses à apprendre. En tout cas, merci nicroman pour cette "leçon" . Et bien vue le PeinardToutSeul.

[ChPr]

Je vous remercie pour ces réponses et rafraichissement de mémoire de la syntaxe objet.

Pour autant :

"formerLgn" et "formerLigne" ne sont qu'une erreur de recopie. C'est bien formerLgn dans les deux cas. Pour moi, Lgn veut dire "ligne" et non pas "login", comme quoi, quand on n'écrit pas explicitement les choses, chacun y voit ce qu'il veut y voir : pour moi, PTS est l'abréviation de Points. Depuis longtemps, j'ai pris l'habitude (mauvaise) d'utiliser des abréviations pour ne pas avoir des lignes de code trop longues

Maintenant, nicroman, quand tu dis :

"va "crasher" avec un joli NullPointerException, parcequ'on utilise l'opérateur '+' entre une String (à gauche) et un objet (à droite)."

Dans mon cas, date n'est pas un objet "Date", mais un "String", donc, ce sont ne sont que des "String" que j'utilise.

Par ailleurs, ce que je n'ai pas écrit, est qu'avant de récupérer des valeurs, je les avais initialisées et donc elles ne valaient pas "null".

Une autre manip montre que le problème est ... un problème : si dans ma classe PTS, je remplace :

Code :

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

return nom+date;

par

Code :

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

return "ZZ";

ça plante toujours !

Minicalion a raison, il faut exploiter le fichier log avant de l'ouvrir (désolé, je n'y suis pas habitué). En fait, le problème vient d'une erreur de formatage d'un entier à l'intérieur de la méthode "formerLgn", j'avais écrit :

Code :

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

		Al = String.format(Locale.US, " %05.0f", Alt);

au lieu de

Code :

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

		Al = String.format(Locale.US, " %05d", Alt);

A ma décharge, cette erreur n'avais pas provoqué de plantage dans une autre procédure où j'utilisais la même instruction ???

En conclusion, ma procédure formaterLgn, malgré ma syntaxe boiteuse (que je dois corriger) fonctionne très bien.

Néanmoins, je ne peux que vous remercier pour votre aide constante.

Cordialement.

Pierre.

[ChPr]

... A ma décharge, cette erreur n'avais pas provoqué de plantage dans une autre procédure où j'utilisais la même instruction ??? ...

Oui, mais parce qu'à cet endroit, la variable était un "float".

Java est bien plus cohérent que moi.

Cordialement.

Pierre