static method should be accessed in a static way

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:

---

1 2	SuperClass.ConteneurMethode1.Traitement();

---

La correction proposée est

Code:

---

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
;)

Je vois pas le rapport entre ca

Code:

---

1 2	SuperClass.ConteneurMethode1.Traitement();

---

et ca

Code:

---

1 2	NomPackage.ConteneurMethode1.Traitement();

---

Soit tu met

Code:

---

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

---

Soit tu met

Code:

---

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.

Citation:

---

Envoyé par b_lob

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.

Citation:

---

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

---

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

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

Code:

---

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

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:

---

Logger.logBadValue.LogInvalidInt("toto");

---

est strictement le même que

Code:

---

Machin.LogInvalidInt("toto");

---

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

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

Merci pour vos réponses et leurs rapidités !

Je reste pourtant convaincu qu'il est intéressant de pouvoir accéder facilement de la même manière au service d'enregistrement des informations ou erreurs

Dans l'histoire, il n'y a pas d'instance de classe mais juste une classe contenant un champ statique sur lequel j'invoque une méthode statique.

Je sais pas si cela relève de la philosophie mais cela me semble très clair et pratique dans mon code. J'ai pas envie d'avoir a instancier un logger pour pouvoir écrire un seul message.

Maintenant si je veux pratiquer cela c'est que je n'avais pas ce genre d'erreur en .net

Je crois que je dois oublier cette solution si je ne veux pas avoir de warning.. :cry:

En tous cas, merci pour vos riches contributions

Citation:

---

Envoyé par b_lob

Je reste pourtant convaincu qu'il est intéressant de pouvoir accéder facilement de la même manière au service d'enregistrement des informations ou erreurs

---

Je ne vois pas ce qu'il y a de compliqué ou de différent.

Citation:

---

Envoyé par b_lob

Dans l'histoire, il n'y a pas d'instance de classe mais juste une classe contenant un champ statique sur lequel j'invoque une méthode statique.

---

Tu dois te tromper. Si tu as ce warning c'est justement parce qu'il y a une instance de classe. (Et qu'il ne devrait pas y en avoir pour appeler du contexte statique.)

Citation:

---

Envoyé par b_lob

Je sais pas si cela relève de la philosophie mais cela me semble très clair et pratique dans mon code. J'ai pas envie d'avoir a instancier un logger pour pouvoir écrire un seul message.

---

Appeler une méthode statique à travers une instance est tout sauf clair : cela laisse entrevoir que la méthode réellement appelée dépendra de l'implémentation fournie par la classe réelle de l'instance, au runtime. Ce qui n'est pas le cas : en contexte statique cela ne dépend que du type déclaré, visible au compile-time.
Très contre-intuitif.

Citation:

---

Envoyé par b_lob

Dans l'histoire, il n'y a pas d'instance de classe mais juste une classe contenant un champ statique sur lequel j'invoque une méthode statique.

---

Et le champ statique, si c'est pas une isntance, tu m'expliquera ce que c'est :)

Le champ statique n'est pas une instance puisque je ne fais pas de new.

Voilà ma structure

Code:

---

1 2 3 4 5 6 7 8

public class Logger {   public static LoggerBadValue; public static LoggerBadData;   }

---

Code:

---

1 2 3 4 5 6 7 8

public class LoggerBadValue { public static void LogInvalidInt(Object value) { //... } }

---

Apres, si vous me dites que le compilateur crée une instance pour mes champs statiques, je veux bien comprendre que cela soit contre intuitif.

Merci de vos remarques !

désolé mais ça

Code:

---

1 2 3 4 5 6 7

public class Logger {   public static LoggerBadValue; public static LoggerBadData;   }

---

ca compile pas, il manque soit le nom du champ, soit le type du champ dans tes déclarations.


Et si t'as pas attribué de valeur, ton code est encore pire, tu appelle délibérément des méthodes sur des instance nulle, bonjour l'incohérence.
Ton code sera beaucoup plus propre, court, cohérent et lisible en faisant:

Code:

---

1 2	LoggerBadValue.LogInvalidInt("toto");

---

plutot que

Code:

---

Logger.logBadValue.LogInvalidInt("toto");

---

un point qui n'as pas été soulevé ici mais qui a son importance. La résolution des méthodes statique se fait à la compilation, alors que les méthodes non statiques, pour la plupart, se font à l'exécution.

Dans ta notation, si je change demain LoggerBadValue par LoggerBadValueNew dans la déclaration de Logger, toutes les classes qui n'auront pas été recompilée continueront d'appeler LoggerBadValue, ce qui n'est probablement pas ce que tu cherche à faire.

Citation:

---

Envoyé par tchize_

un point qui n'as pas été soulevé ici

---

Je sais pas ce qu'il te faut, je l'ai dit deux fois -_-°.

Effectivement, il manquait le nom du champ :

Code:

---

1 2 3 4 5 6 7 8

public class Logger {   public static LoggerBadValue loggerBadValue; public static LoggerBadData loggerBadData;   }

---

je crois comprendre qu'il n'y a pas de classes statiques et donc comme le dit thelvin, il est normal que j'ai ce warning.
Je voulais utiliser cette structure car nous sommes plusieurs à travailler sur le projet et il est plus simple pour rapidement logger n'importe quel message de passer par le même chemin

Bref, merci pour vos contributions !

Il est tout-à-fait possible de faire des classes membres statiques, mais ce n'est pas ce qu'on voit là.

Par exemple on pourrait faire :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public class Logger {   public static class LoggerBadValue { public static void logInvalidInt(String message) { // log } }   public static class LoggerBadData { public static void logBadInt(String message) { // log } }   }

---

Ce qui s’appellerait à coup de :

Code:

---

Logger.LoggerBadValue.logInvalidInt("je l'aime pas ce int");

---

Il m'arrive parfois de faire ce genre de constructions. (Mais pas pour loguer : ça manque de contexte.)

C'est exactement ce que j'aurai aimé Thelvin !

Si ce n'est que mes classes ne sont pas imbriquées. Apparemment le modificateur static n'est valide que pour les classes imbriquées ...

Merci pour avoir insisté. :ccool:

Citation:

---

Envoyé par b_lob

Si ce n'est que mes classes ne sont pas imbriquées. Apparemment le modificateur static n'est valide que pour les classes imbriquées ...

---

Ah ben oui, 'faut les déplacer, c'est sûr, mais bon je croyais que c'était important pour toi.
Et puis c'est aussi pour informer...

Plusieurs interfaces / classes de Java2D utilisent ce type de construction : Point2D, Line2D, Path2D, etc. entre autre pour fournir deux implémentations concrètes de l'interface / classe mère : Float et Double (ex: les classes Point2D.Float et Point2D.Double contenues et definies dans la classes abstraite Point2D).

Dans le meme genre j'aime bien souvent regrouper mes renderers (resp editors) Swing pour certains types d'objets avec TotoRenderer et TotoRenderer.List, TotoRenderer.Table et TotoRenderer.Tree vu que grosso-modo leur fonctionnement/apparence est commune ou similaire.