Discussion :

[b_lob]

Bonjour,

je dispose de methodes static sur des classes que j'ai regroupé dans une superClass de maniere statique.

Certes c'est pas tres objet, mais pour le coup, cela m'arrange.

J'ai le warning
static method should be accessed in a static way quand je fais

Code :

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

1
2
 
SuperClass.ConteneurMethode1.Traitement();

La correction proposée est

Code :

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

NomPackage.ConteneurMethode1.Traitement();

Or, j'ai envie de conserver la superClass visible pour profiter de l'intellisence et aussi pour garder la cohérence avec laquelle j'ai commencer de coder.

Y a t-il quelque chose à faire pour palier à ce warning ?

Merci

[tchize_]

Je vois pas le rapport entre ca

Code :

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

1
2
 
SuperClass.ConteneurMethode1.Traitement();

et ca

Code :

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

1
2
 
NomPackage.ConteneurMethode1.Traitement();

Soit tu met

Code :

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

1
2
 
nom.de.package.NomDeClasse.methode()

Soit tu met

Code :

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

1
2
3
4
 
import nom.de.package.NomDeClasse;
.....
NomDeClasse.methode()

Il viens d'ou ce "SuperClass". tu peux nous donner le code concret (tes imports, ta déclaration de class, ta déclaration de méthode et ton appel) qu'on y voie plus clair? Une classe statique doit toujours etre accédée via un nom de classe, jamais via une instance.

[thelvin]

Or, j'ai envie de conserver la superClass visible pour profiter de l'intellisence et aussi pour garder la cohérence avec laquelle j'ai commencer de coder.

L'intellisense ne disparaîtra pas.

Il n'y a pas de cohérence dans le fait d'appeler une méthode statique en passant par un nom de variable. Seulement un nom de classe. C'est également générateur de bugs, bien que cela soit peu probable dans la situation actuelle telle que tu la décris.

Y a t-il quelque chose à faire pour palier à ce warning ?

Oui, mais les seules raisons de le faire sont mauvaises.

[b_lob]

Merci pour vos réponses.. Cela m'embete de ne pouvoir écrire simplement

Code :

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

1
2
3
4
 
Logger.logBadValue.LogInvalidInt("toto");
 
Logger.logBadData.LogInvalidPeriod(Periode)

Le logger est statique et les champs sont statiques aussi... Et je vois pas pourquoi ca devrait contrarier le compilateur mais bon..

Si vous avez d'autres pistes..

[tchize_]

Le compialteur, a raison te dit que LogInvalidInt est une méthode "statique" de la classe instanciée par logBadValue et que, donc, tu dois accéder à cette méthode via le nom de classe et non via une instance. Je ne sais pas de quelle classe est logBadValue, mais si sa classe est Machin, alors ce code

Code :

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

Logger.logBadValue.LogInvalidInt("toto");

est strictement le même que

Code :

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

Machin.LogInvalidInt("toto");

[thelvin]

Ben, pas exactement, et c'est bien là le problème.

La classe réelle de l'objet logBadValue n'est pas vérifiée. Dans le cas de méthodes statiques, c'est le type déclaré de cette variable, qui est utilisé. Raison pour laquelle c'est une très mauvaise idée de l'écrire comme ça.

Le compilateur n'est pas plus contrarié que ça, il dit juste "Oooh, toi t'es en train de faire une connerie !" Heureusement qu'il est là pour le dire. (Note : il dit pas "je crois que tu es en train de..." il dit "tu es en train de...")

[Rastafire]

Enfin reste qu'avoir du static pour un logger je suis pas sûr d'en saisir l'intérêt personnellement... Tu es sûr que ce soit vraiment nécessaire dans ton cas? Si ça ne l'est pas je pense que tu vas chercher loin pour pas grand chose u_u