Public variable

Questions à propos du scripting. Hors Shader, GUI, Audio et Mobile.
Edrahil511
Messages : 15
Inscription : 13 Déc 2020 16:54

Public variable

Message par Edrahil511 » 18 Mars 2021 14:48

Salut a tous,

Je poste ici car je m'interroge sur ce que je peux voir un peu partout sur internet.

Dans tout les tutos que j'ai pu voir je tombe sur des personnes qui déclarent leurs variables en public. Hors lors de mon apprentissage en autodidacte de la POO (en c++) si il y a bien un truc que j'ai compris c'est que jamais ô grand jamais on ne déclarait les attributs d'une class en public. Tant que je voyais ça dans des tuto random je ne me posais pas trop de questions ne sachant pas qui se cachait derrière ce dernier mais la je suis en train de lire le livre de Anthony Cardinale sur Unity3D (quelqu'un de callé sur le sujet visiblement et un livre qui a été relu par plusieurs personnes avant publication) et je vois qu'il fait la même chose.

Il met des attributs en public en expliquant :
- Qu'une variable public sera visible dans l'inspector et une variable privé non (oui mais n'est ce pas plutôt l'utilisation d'un [SerializeField] qui est fait pour ça ?)
- Une variable en public est accessible par les autres script (pas faux mais moi j ai appris qu'il fallait faire des methodes Get pour les récupérer justement)

Au final la règle de la POO que je m'efforce de suivre disant que les attribut doivent toujours être privé est bel et bien juste ou est elle finalement futile ? Car je n'ai jamais vu quelqu'un parler de l'encapsulation sur unity3D et c'est la foire à la saucisse tout le monde met des variables en public. Respecter l'encapsulation ne demande pas beaucoup d'effort supplémentaire alors pourquoi personne ne le fait ? Est ce une erreur visible partout ou on s'en fou finalement ?

Avatar de l’utilisateur
boubouk50
ModoGenereux
ModoGenereux
Messages : 5573
Inscription : 28 Avr 2014 11:57
Localisation : Toulouse

Re: Public variable

Message par boubouk50 » 18 Mars 2021 15:47

La variable publique est une facilité.
Personnellement, je déclare pratiquement tout en private (ou protected) et j'expose les variables avec le [SerializeField].
Je le fais par convention et respect des règles, mais pourquoi exactement faut-il les suivre, je ne saurais te dire...
"Ce n'est pas en améliorant la bougie, que l'on a inventé l'ampoule, c'est en marchant longtemps."
Nétiquette du forum
Savoir faire une recherche
Apprendre la programmation

Avatar de l’utilisateur
DevAmat
Messages : 390
Inscription : 23 Nov 2016 11:50

Re: Public variable

Message par DevAmat » 18 Mars 2021 15:50

Salut,

Il ya un écart entre la manière de faire du C# dedans et en dehors de Unity.

Personnellement je m'efforce à mettre le maximum de chose en "private" et de ne donner l'accès que si nécessaire via un "Get / Set" ou un "protected". Mais il est vrai que dans le cas de Unity parfois cela peut paraitre superflu. Mais cela permet de savoir ce qui est atteint juste via l'inspecteur ou ce qui est potentiellement atteint de partout, et d'un point de vue architecture cela peut mettre en évidence une mauvaise architecture ou éviter de créer une mauvaise architecture.

Donc je te conseille au final de suivre les bonnes pratiques et de donner accès à la variable que si nécessaire.

Edrahil511
Messages : 15
Inscription : 13 Déc 2020 16:54

Re: Public variable

Message par Edrahil511 » 18 Mars 2021 16:23

D'accord si je comprends bien ce n'est pas une hérésie de ne pas suivre cette règle lorsqu'on développe sur Unity car elle a moins d'importance ou de sens mais les développeurs qui ont ou eu l'occasion de travailler avec des langages orientés objets en dehors d'unity garde leurs habitudes et bonnes pratiques de ces derniers ?

Perso j aime être bon élève donc oui je continuerai à mettre en privé ::d mais au moins je comprend pourquoi on peut être moins à cheval la dessus dans unity

Avatar de l’utilisateur
jmhoubre
Messages : 407
Inscription : 05 Oct 2019 22:05

Re: Public variable

Message par jmhoubre » 19 Mars 2021 02:09

Pareil. Des variables private c'est plus propre.

Répondre

Revenir vers « Scripting »