Discussion :

[patator_]

Bonjour,

Je me pose plusieurs questions, alors je les regroupe ici.

1. Quelle est la différence les deux codes suivant ? Une des deux solutions est elle meilleure que l’autre ?
   
   

   Code :

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

   1
   2
   3
   4
   5
   public class toto{
       JPanel panel = new JPanel();
    
       public toto(){}
   }

   Code :

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

   1
   2
   3
   4
   5
   6
   7
   public class toto{
       JPanel panel;
    
       public toto(){
           panel = new JPanel();
       }
   }

2. Je ne vois pas l'intérêt d'utiliser 'private static final' avec un getter plutôt que 'public static final'.
   Il y a une réponse dans ce sujet mais je n'en comprends pas la subtilité.
   https://stackoverflow.com/questions/...al-with-getter
   
3. Imaginons un mini jeu constitué d’un plateau sur lequel se déplace un joueur (avec les coordonnées x et y). Il ne doit pas pouvoir franchir des obstacles situés sur le Plateau ni pouvoir sortir des limites du Plateau.
   J’ai une classe Plateau (héritant de JPanel) et une classe Player. Le Plateau a donc un Player et des obstacles (mettons qu’un obstacle est un Point).

Pour déplacer mon joueur, je crée une méthode movePlayer. Où dois-je placer cette méthode ?
Dans Plateau ? => je gère plus facilement le déplacement car j’ai les coordonnées des obstacles, les limites du plateau et le joueur. Cependant, ça paraît contre-intuitif d’utiliser le plateau pour déplacer le joueur ?
Dans Joueur ? => ça paraît plus logique, c’est le joueur qui se déplace. Je modifie ses coordonnées pour le déplacer. Mais comment aller chercher proprement les infos qui me permettent de vérifier que je joueur a bien le droit d’effectuer ce déplacement ? Si le jeux se complexifie, cette étape de vérification peut être amenée à prendre en compte beaucoup d’informations.

Merci d'avance

[thelvin]

1) Quelle est la différence les deux codes suivant ?

Présenté comme ça, rien d'évident. Le résultat est le même.

Maintenant voyons deux exemples plus compliqués :

Code :

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

1
2
3
4
5
6
7
8
9
10
public class toto{
    JPanel panel = new JPanel();
    String name;
 
    public toto(){}
 
    public toto(String name){
      this.name = name;
    }
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
public class toto{
    JPanel panel;
    String name;
 
    public toto(){
        panel = new JPanel();
    }
 
    public toto(String name){
        panel = new JPanel();
        this.name = name;
    }
}

Notre classe toto a maintenant une variable name.
Ce n'est pas obligatoire de lui donner une valeur mais on peut. Alors on a deux constructeurs : un qui donne une valeur à name, et l'autre qui la laisse sans valeur.

Et là ben on voit bien que le deuxième exemple se répète, à faire la même chose dans tous les constructeurs, alors que le premier l'a fait dès le début avant les constructeurs.

La différence entre les deux notations, se situe dans l'ordre d'exécution quand on crée une nouvelle instance d'une classe. Bref quand on fait new toto().

1. Appel du constructeur de la classe parente (si pas de classe parente explicite, c'est la classe Object)
2. Initialisation des variables
3. Exécution du constructeur appelé

Et donc, quand tous les constructeurs sont censés initialiser une variable de la même manière, il peut sembler plus simple de le faire à la déclaration de cette variable plutôt que dans les constructeurs.

Une des deux solutions est elle meilleure que l’autre ?

Oui, la bonne. C'est à dire celle qui t'arrange le mieux dans la situation dans laquelle tu es.

2) Je ne vois pas l'intérêt d'utiliser 'private static final' avec un getter plutôt que 'public static final'.

Quand on prend un cas unique et isolé, en général moi non plus.

Mais dès qu'on généralise, disons qu'il y a des vraies raisons qui apparaissent, et qu'au moins, la solution du getter systématique "rassure", qu'il évite les surprises.

Imagine que ta variable static soit d'un type mutable. Par exemple un tableau. Tu as peut-être pas envie que n'importe qui puisse allez modifier son contenu et ainsi affecter tout le reste du code qui veut utiliser cette variable. Un getter aura au moins la possibilité, si on se rend compte que c'est nécessaire, de créer une copie de la variable et d'envoyer ça à la place, sans risque de modifier la variable originelle.

Prenons les enums par exemple, prenons java.time.Month, qui énumère les mois de l'année.
Comme tous les enums, il a une méthode values() qui renvoie un tableau qui contient toutes les valeurs de l'enum.
Et comme c'est un tableau, on peut changer son contenu tant qu'on veut, et inverser JANUARY et APRIL par exemple.
Bon ben si le gars qui a demandé ces valeurs s'amuse à les inverser, c'est son problème. Ça ne touchera pas le reste du programme. Parce qu'un appel à values() renvoie chaque fois un tableau nouvellement créé, qui contient toutes les valeurs. Une copie donc, de la liste de toutes les valeurs.
Tu imagines si ça n'avait pas été un accesseur, la méthode values(), mais juste une variable, public static Month[] values; ?
Le moindre petit bout de code dans une dépendance de Spring pourrait inverser JANUARY et APRIL, ou bien tout mettre à null, et ainsi casser le code de tout le reste de l'application.

Mieux vaut, donc, un accesseur quand la variable est d'un type mutable. C'est un exemple.

Il y a une réponse dans ce sujet mais je n'en comprends pas la subtilité.
https://stackoverflow.com/questions/...al-with-getter

Ça c'est un peu le problème inverse, c'est un exemple de quand les constantes en Java sont problématiques.

Java a une notion précise de trucs qui sont des constantes.
En gros c'est une variable, de type primitif ou String, dont la valeur ne change pas, et qui est connue à la compilation.
typiquement, public static final int FOO = 5; est une constante. Type int donc primitif, final donc ne change pas, initialisé tout de suite, et à 5 qui est un littéral donc le compilateur sait ce que c'est.

Le truc avec les constantes, c'est que le compilateur les remplace par leurs valeurs, puisqu'il la connaît. Il ne dit pas qu'il faudra aller chercher la valeur de la constante au moment de l'exécution. Il dit ah oui, FOO c'est une constante de valeur 5, donc je mets pas FOO je mets 5. Et après compilation, le programme n'est même plus au courant qu'il y avait une constante impliquée dans l'affaire.

On sait qu'un programme Java prêt à l'exécution, c'est un ensemble de fichiers *.class. Ce sont des fichiers binaires. Chacun de ces fichiers est le résultat de la compilation des classes écrites en Java dans des fichiers .java.
Imaginons, dans mon programme, ma classe A va aller regarder la valeur de la variable non-constante v de ma classe B. Pas de problème, l'exécution trouve la classe B qui était décrite par B.class et récupère la variable qu'elle contient.
Maintenant, A va s'intéresser à la variable constante w de la classe C. Mais là la valeur de cette constante est déjà connue à l'exécution. Aucune raison d'aller s'intéresser à C, et si ça se trouve le fichier C.class a été complètement ignoré et pourrait aussi bien ne pas être là. Si on le remplaçait par un autre, en tout cas, ça n'aurait aucun effet.

Bon, et du coup et alors ? Ça ressemble à une simple optimisation bien légitime faite par le compilateur.

Eh bien voilà. Imagine tu utilises une bibliothèque tierce pour faire quelques calculs d'équations physiques.
Cette bibliothèque, en version 1.0, déclare cette constante :

Code :

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

public static final double CONSTANTE_GRAVITATIONNELLE = 6.7;

Et les gens se servent de cette bibliothèque et de cette constante et tout, mais plus tard on leur fait remarquer :
"Euh ouais les gens, sinon, vous pensez pas que vous auriez pu être un chouïa plus précis que juste un chiffre après la virgule, non ?"

Bon, alors ils sortent la version 1.1, avec cette nouvelle constante :

Code :

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

public static final double CONSTANTE_GRAVITATIONNELLE = 6.67408;

Là c'est cool. Les gens sont contents de la précision de la constante.
Dans leur programme qu'ils ont installé partout, ils remplacent donc la bibliothèque 1.0 par la version 1.1, car elle est compatible au niveau binaire comme presque toujours, et quand le programme tourne... Il continue d'être aussi imprécis qu'avant.
Parce que la constante n'était pas lue dans les binaires de la bibliothèque. Elle est incluse dans chaque endroit du programme qui la lisait.
Pour mettre à jour, il faut recompiler entièrement le programme avec cette version 1.1, et réinstaller partout cette nouvelle version du programme, pas juste de la bibliothèque.

Et ça, c'est considéré peu pratique par pas mal de gens.

Enfin dans le monde professionnel moderne, quand on change une version d'un bibliothèque, on commence par repasser toutes les suites de tests. Ce qui inclus de recompiler d'abord. Et les programmes validés, ce sont ceux qui ont passé les tests, donc ceux qui ont été recompilés. Le problème décrit au-dessus n'est pas censé exister quand on travaille avec des professionnels. Mais, on peut pas toujours, donc...

3) [Jeu de plateau]

[...] Cependant, ça paraît contre-intuitif d’utiliser le plateau pour déplacer le joueur ?

Utiliser le plateau pour déplacer le joueur, oui.
Que le plateau soit l'autorité finale à informer de quelle est la position du joueur, non.

C'est lui qui est en charge de savoir où est le joueur, donc c'est lui qui sait ce qu'il doit faire quand cette position change.

Si tu as des règles à faire respecter en cas de tentative de faire bouger le joueur, qui pourrait échouer, tu peux confier ça à une classe RegleDeDeplacement, qui devrait être appelée par un truc, qui juste après, si validé, appellera Plateau pour lui dire que Joueur a changé de place.

[patator_]

Super merci pour la réponse détaillée, j'ai tout compris :p