discours sur la methode

Citation:

---

je vois qu'on peut déclarer et même initialiser une variable aussi bien dans le constructeur que dans les déclaration avant le constructeur.

---

En terme de déclaration il y a une différence fondamentale entre ces 2 manières de faire.

Un constructeur est une méthode (spéciale d'accord, mais méthode), et toute déclaration dans une méthode crée une variable locale (qui n'est disponible que dans la méthode qui la crée).

Par contre une variable déclarée hors constructeur (hors méthode j'entends) crée soit une variable de classe, soit une variable d'instance, qui sont fondamentalement différente des variables locales. Ce n'est pas parce qu'elle est déclarée dans une constructeur qu'elle fera propriété.

En conclusion si tu déclares cas dans le constructeur, tu changes ta classe.

Citation:

---

Envoyé par welcome_59

En terme de déclaration il y a une différence fondamentale entre ces 2 manières de faire.

Un constructeur est une méthode (spéciale d'accord, mais méthode), et toute déclaration dans une méthode crée une variable locale (qui n'est disponible que dans la méthode qui la crée).

Par contre une variable déclarée hors constructeur (hors méthode j'entends) crée soit une variable de classe, soit une variable d'instance, qui sont fondamentalement différente des variables locales. Ce n'est pas parce qu'elle est déclarée dans une constructeur qu'elle fera propriété.

En conclusion si tu déclares cas dans le constructeur, tu changes ta classe.

---

Oui, oui, j'ai bien compris la nuance.

Mais ma question portait uniquement sur les variables de classe, initialisées soit dans le constructeur ou soit 'en ligne', il s'agissait de savoir s'il y avait une différence et/ou des préconisations en la matière.

Citation:

---

Envoyé par adiGuba

Salut,

Tu peux tout à fait mettre cela dans le constructeur : this est parfaitement valable dans le constructeur !
De plus le code d'initialisation est exécuté avant le code du constructeur, donc je ne vois pas pourquoi cela ne marcherais pas dans le constructeur...

Ce qui me gène surtout dans ce code ce sont les règles de nommage qui ne sont pas respecté et même inversé (nom de classe qui commence par une minuscule / nom de variable qui commence par une majuscule). Il me semblais qu'il y avait une erreur quelque part mais je ne la trouvais pas :aie:

a++

---

+1 pour mon histoire de this qui pose problème dans le constructeur, je suis retombé sur le problème (à un endroit où ça n'en avait d'ailleurs jamais posé, bref.)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

public class PanelJoueurs extends Vue {   /**          *          */ private static final long serialVersionUID = 1L; private JLabel [] listeJ; private JLabel attente; private JButton go; private Box vertical;   public PanelJoueurs () { vertical = Box.createVerticalBox(); vertical.setAlignmentX(Box.LEFT_ALIGNMENT);   [....]   add(vertical); TableauJoueurs.getInstance().newletter(this); }

---

il s'agit d'abonner mon composant à un tableau qui va être actualisé
a l'autre bout, j'ai ça :

Code:

---

1 2 3 4 5

public void newletter (Vue p) { abonne.add(p); duneuf(); }

---

où abonne est un HashSet.

Ca me renvoie un javanullpointerexception.

Alors je crois bien avoir lu qu'un constructeur ne devrait appeler que des méthodes static, comme je le disais, instinctivement, j'ai l'impression qu'un this dans un constructeur c'est quelque chose de pas complètement défini (pas complètement construit), mais toi tu me dis que je peux utiliser this dans le constructeur. Alors je ne vois pas comment contourner le problème...

Citation:

---

Envoyé par firgon

Alors je crois bien avoir lu qu'un constructeur ne devrait appeler que des méthodes static, comme je le disais, instinctivement, j'ai l'impression qu'un this dans un constructeur c'est quelque chose de pas complètement défini (pas complètement construit), mais toi tu me dis que je peux utiliser this dans le constructeur. Alors je ne vois pas comment contourner le problème...

---

Tu peux utiliser this dans le constructeur !
Le seul endroit où tu ne peux pas l'utiliser c'est lors de l'appel à super() en tout début du constructeur, mais l'utilité est quasi-nulle...

Dans ton cas c'est une erreur de développement ! D'ailleurs c'est quasiment toujours le cas avec un NullPointer ! Il faudrait avoir le stacktrace complet et un peu plus d'info sur le code correspondant...

a++

ok Mille milliards d'excuses, c'était effectivement la variable abonne qui avait un problème...

:traine: Retourne se cacher dans sa grotte

Bon j'ai trouvé la solution à ma deuxième question :

dans chaque classe j'ai inséré :

Code:

---

private Image fond = new ImageIcon (getClass().getResource("/img/"+getClass().getSimpleName()+"/fond.jpg")).getImage();

---

comme ça pour chaque classe et de façon quasi-automatique, la classe (qui extends JPanel va chercher le fond qui lui est propre c'est à dire : img/nomdelaclasse/fond.jpg

Je sais pas si j'ai beaucoup fait avancé le schmilblick mais ça me permets de simplifier la gestion de mes images de fond (toujours le même nom, toujours la même ligne de code)

Je suis toujours dans mes questionnements sur la bonne méthodea employer.

Je tente toujours de vider mon code de tout ce qui pourrait être en dur.

Comme il est toujours possible (par exemple) que mon application java, change de site web de rattachement (multiples liens html, zone de mise à jour, etc...), plutôt que de mettre un peu partout dans mon code des String 'en dur', j'aurai voulu utilisé un moyen plus souple.

J'ai beaucoup utilisé ResourceBundle mais on le déconseille parce qu'il sert surtout à la traduction.

Alors j'ai eu l'idée de créer une class Data avec des final static String. Et maintenant je met partout dans mon code Data.nomDuSite + Data.dossierTelecharg + Data.fichierzip.

Mais comme c'est une idée qui m'est venue tout seul, je me dit que c'est peut-être pas une bonne idée, et en tout cas, surement pas la meilleure, il doit y avoir des us et coutumes plus appropriés. Si oui, lesquels ?

D'avance merci.

L'utilisation des ResourceBundle est à réserver aux traudctions, mais tu peux t'appuyer sur une autre classe qui permet de stocker des paramètres dans un fichier : Properties.

C'est basé sur un fonctionnement très simple de clé/valeur, il suffit d'appeler les méthodes load ou loadFromXML pour charger le fichier, et store ou storeToXML pour sauvegarder. C'est exactement cela qu'il faut utiliser pour des paramètres de configuration.

Ah oui, j'ai vu ces properties, mais en quoi c'est préférable à mon système. Quels sont les risques ?

Encore une fois, qu'on me comprenne bien, le but est pas de remettre en cause les regles qu'on me donne, je veux juste comprendre pourquoi c'est mieux de faire comme ça (avec Properties) plutôt que comme ceci (avec Data.class). Pour l'instant de mon point de vue de débutant ça me prend une instruction avec Data.nomDeCeQueJeVeux et plusieurs lignes de code avec properties.

Mais je suis persuadé que c'est un maigre avantage.

Salut,


Les final static String sont des constantes, et donc la moindre modification nécessitera la recompilation de tout le code.

Les fichiers *.properties sont des fichiers texte chargé au démarrage. C'est parfait pour un fichier de config puisque cela peut être édité simplement. De plus ils permettent la surcharge des valeurs (par exemple on charge un fichier avec les valeurs par défaut, puis un fichier "utilisateur" contenant des valeurs spécifique).


Après bien sûr cela dépend de ce que tu veux faire...


a++

Je comprends. Je te remercie, c'est très clair à présent.

Je poursuit mes interrogations existentielles.

La plupart de mes class main ressemblent à ça :

Code:

---

1 2 3 4 5 6 7 8

public class Serveur {   public static void main (String arg[]) { new fenetreserveur();   }   }

---

Je me demande si je fais bien. Parce qu'en fin de compte, il se passe pas grand chose dans ma class main, elle se contente de passer la main (ouarf ouarf oaurf).
Est-ce que c'est normal, une class main est souvent réduite à peu de chose? Est-ce que j'oublie d'exploiter une fonctionnalité importante des classes main ?
Je m'interroge. Enfin je vous interroge aussi un peu.