Utilité concrète du mot clé "private"
Résolu/Fermé
A voir également:
- Utilité concrète du mot clé "private"
- Clé windows 10 gratuit - Guide
- Clé usb non détectée - Guide
- Voir mot de passe wifi android - Guide
- Trousseau mot de passe iphone - Guide
- Mot de passe administrateur - Guide
3 réponses
KX
Messages postés
16753
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
25 novembre 2024
3 020
1 sept. 2017 à 08:37
1 sept. 2017 à 08:37
Bonjour,
"en tant que créateur de mon logiciel, je ne vois pas pourquoi je ne mettrai pas tout en public"
La programmation objet va plus loin que ton seul logiciel, un certain nombre de bibliothèques sont disponibles qui contiennent des multitudes de classes, mais dont l'utilisation est donnée à des développeurs qui n'ont pas eux même conçu la classe en question, n'en connaisse pas le fonctionnement, et pourrait la casser s'il accédait directement à des attributs privés.
Par exemple si je construis une liste avec un tableau et un entier pour la taille, lorsque j'ajoute une donnée à la liste je vais la mettre dans le tableau et augmenter la taille de 1, si ces attributs ne sont pas privés n'importe qui pourrait venir ajouter ou supprimer des éléments dans le tableau, mais il ne pensera peut être pas à modifier la taille. Ce travail c'est à la méthode d'ajout de le faire, c'est elle qui garantie la cohérence des données pour la classe.
Tout ce qui peut être corrompu et provoquer un état instable de l'objet doit être privé et manipulé uniquement par les méthodes dédiées.
Remarque : cela vaut également pour plusieurs personnes qui travaillent sur le même logiciel, en même temps, ou successivement tout au long de la vie du logiciel. La sécurité des accesseurs permet d'empêcher une mauvaise utilisation de la classe, parce que quand tu récupères un projet de plusieurs milliers de classes, la plupart tu ne sais pas à quoi elles servent ou comment elles fonctionnent, elles sont d'ailleurs peut être bogués, donc la prudence est de rigueur mais si c'est publique c'est qu'on peut faire ce que l'on veut sans risque.
"en tant que créateur de mon logiciel, je ne vois pas pourquoi je ne mettrai pas tout en public"
La programmation objet va plus loin que ton seul logiciel, un certain nombre de bibliothèques sont disponibles qui contiennent des multitudes de classes, mais dont l'utilisation est donnée à des développeurs qui n'ont pas eux même conçu la classe en question, n'en connaisse pas le fonctionnement, et pourrait la casser s'il accédait directement à des attributs privés.
Par exemple si je construis une liste avec un tableau et un entier pour la taille, lorsque j'ajoute une donnée à la liste je vais la mettre dans le tableau et augmenter la taille de 1, si ces attributs ne sont pas privés n'importe qui pourrait venir ajouter ou supprimer des éléments dans le tableau, mais il ne pensera peut être pas à modifier la taille. Ce travail c'est à la méthode d'ajout de le faire, c'est elle qui garantie la cohérence des données pour la classe.
Tout ce qui peut être corrompu et provoquer un état instable de l'objet doit être privé et manipulé uniquement par les méthodes dédiées.
Remarque : cela vaut également pour plusieurs personnes qui travaillent sur le même logiciel, en même temps, ou successivement tout au long de la vie du logiciel. La sécurité des accesseurs permet d'empêcher une mauvaise utilisation de la classe, parce que quand tu récupères un projet de plusieurs milliers de classes, la plupart tu ne sais pas à quoi elles servent ou comment elles fonctionnent, elles sont d'ailleurs peut être bogués, donc la prudence est de rigueur mais si c'est publique c'est qu'on peut faire ce que l'on veut sans risque.
Utilisateur anonyme
1 sept. 2017 à 09:04
1 sept. 2017 à 09:04
Bonjour, en complémentent de la réponse très explicite de KX (que je salue au passage), imaginons un jeune médecin qui décide d'écrire un logiciel pour gérer sa patientèle.
Il est le seul développeur et pourrait avoir la même réaction que toi.
En tant que médecin, il doit identifier avec certitude les patients. Or il existe des homonymes, donc le nom et le prénom ne suffisent pas.
Donc ce médecin utilise le numéro de sécu, qui ne doit jamais être modifié, même par inadvertance, et être attribué dès la saisie d'un nouveau patient dans le logiciel.
Dans ce cas, ce numéro est demandé en paramètre au constructeur, attribué à un champ privé et fourni au logiciel par une propriété en lecture seule.
Ainsi même si le numéro est affiché dans une textbox, donc modifiable en apparence, la propriété étant en lecture seule (grâce au champ privé), il n'y aura jamais de modification intempestive de l'utilisateur.
De même, le médecin, 6 mois ou 1 an plus tard, quand il fera évoluer le logiciel, ne pourra pas écrire, par erreur un code qui modifie ce numéro en dehors de la classe Patient.
Il est le seul développeur et pourrait avoir la même réaction que toi.
En tant que médecin, il doit identifier avec certitude les patients. Or il existe des homonymes, donc le nom et le prénom ne suffisent pas.
Donc ce médecin utilise le numéro de sécu, qui ne doit jamais être modifié, même par inadvertance, et être attribué dès la saisie d'un nouveau patient dans le logiciel.
Dans ce cas, ce numéro est demandé en paramètre au constructeur, attribué à un champ privé et fourni au logiciel par une propriété en lecture seule.
Ainsi même si le numéro est affiché dans une textbox, donc modifiable en apparence, la propriété étant en lecture seule (grâce au champ privé), il n'y aura jamais de modification intempestive de l'utilisateur.
De même, le médecin, 6 mois ou 1 an plus tard, quand il fera évoluer le logiciel, ne pourra pas écrire, par erreur un code qui modifie ce numéro en dehors de la classe Patient.