Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
[POO] Visibilité des propriétés
Bonjour,
je comprend bien les notions de private, public, protected etc... mais cependant j'ai juste une difficulté à saisir quand faut il utiliser l'une ou l'autre, dans quel contexte concret doit on rendre une donnée privé ou protected... par défaut je les met en protected et j'ajuste en fonction... mais y'a t'il des règles élémentaires pour identifier les cas concrets d'utilisation de l'une ou l'autre des ces propriétés?
Salut,
normalement, une classe possède tous ces attributs en private ==> principe d'encapsulation. Et n'expose que quelques informations au travers des accesseurs.
Donc normalement ta question devrait être, quand est ce que j'arrête de faire des accesseurs pour laisser la propriété en accès public.
Réponses : Qd tu as un coup de fainéantise, ou quand cela n'a pas d'impact sur le fonctionnement de ton instance.
tout le reste devrait être contrôler en entrée / sortie, et donc en private / protected.
A noter pour ajouter par rapport à ce qui a été dit au dessus, que "protected" est à éviter le plus possible. Cela revient à dire qu'il suffit d'hériter la classe pour briser le principe d'encapsulation.
'faut voir...Envoyé par kaymak
Les notions de portées des attributs ne sont importantes que dans le cadre d'un travail en équipe ou dans la réalisation de modules réutilisables. C'est le principe de la "boîte noire" qu'on utilise sans en connaitre le fonctionnement.
Mais il s'agit juste d'un côté pratique et conventionnel, rien n'interdit de mettre tous ses attributs en accès publique. Voir les conventions de Perl ou par défaut il n'y a pas de variable privée (sauf utilisation de closures) et dont le modèle objet fonctionne très bien.
Parce que franchement, les getters et les setters qui ne font que renvoyer la variable, c'est inutile.
Sans compter les mauvaise utilisations ou on croit blinder un attribut objet en lecture en ne renvoyant qu'un getter public. Le passage par référence fait que l'objet est de toutes façons modifiable.
@jml94 : Voilà, je pense qu'il à le pour et le contre pour juger de ces actes
Pour le reste je suis d'accord avec certains de tes arguments.
Sauf que voilà, un accesseur qui se contente de renvoyer la variable, fait son job, on ne lui en demande pas plus.
Il devient intéressant, selon moi, qd :
- il confirme / valide / force le type
- vérifie les types en entrée
- propose des valeurs par défaut plus cohérente que null
Après je trouve mon code plus consistant et sécurisant avec des getters/setters strict.
Plutôt que de laisser le permissif de php prendre le pas et m'introduire des bugs à se taper le crane.
Mais bon là, c'est un sujet qui pourrait être débattus 10 ans. non?
Effectivement je crois que j'avais pris le problem à l'envers merci de cette vive précision, mais justement en général je suis plutot en mode protected et je passe en mode privé au coup par coup etc... j'aurai juste aimé en fait avoir une ou des petites reglesà suivre ou deux ou trois questions à poser avant de décider entre privé et protected?
Il y a déjà la question basique : cette classe pourra-t-elle être dérivée et si oui, cet attribut devra-t-il être accessible ?
En pratique, protected par défaut me convient très bien.
C'est bien parce que je travaille en équipe en général que je me pose la question, parce que toutes les semaines j'ai des débats sur la porté des attributs d'un object avec mes collegues... je cherchais avoir ques regles utiles à suivre des questions à se poser pour déterminer dans un cas plus ou moins concret la portée d'un attribut voir d'une methode... parce qu'en voila uen autre paire de manche'faut voir...
Les notions de portées des attributs ne sont importantes que dans le cadre d'un travail en équipe ou dans la réalisation de modules réutilisables. C'est le principe de la "boîte noire" qu'on utilise sans en connaitre le fonctionnement.
Mais il s'agit juste d'un côté pratique et conventionnel, rien n'interdit de mettre tous ses attributs en accès publique. Voir les conventions de Perl ou par défaut il n'y a pas de variable privée (sauf utilisation de closures) et dont le modèle objet fonctionne très bien.
Parce que franchement, les getters et les setters qui ne font que renvoyer la variable, c'est inutile.
Sans compter les mauvaise utilisations ou on croit blinder un attribut objet en lecture en ne renvoyant qu'un getter public. Le passage par référence fait que l'objet est de toutes façons modifiable.
Exactement !
Exactement !Mais bon là, c'est un sujet qui pourrait être débattus 10 ans. non?
En fait la question que tu me pose me fait réaliser qu'on en peut pas déterminer de règles générales sur l'utilisation de ces access controls, en effet est ce que par exemple dans une classe Users (membre enregistrés) qui peut être étendue en une classe UsersPayant (membre payant), les attributs password et userLogin doit etre privée ou protected et de meme est ce que la méthode changePassword par exemple est private ou protected?
Cela dépend si le fait de modifier la dite propriété influe sur le comportement de l'instance.
Si j'ai une class A avec un libelle, à priori je peut laisser en public cela ne risque pas de flinguer l'objet.
Par contre si j'ai un iterateur, la propriété qui indique la position courante, doit rester privée, puisque si elle est modifié depuis l'extérieur, cela risque de casser complètement le fonctionnement de mon itérateur.
Fin bon après il y à surement des gens plus compétent qui pourront t'expliquer mieux que moi, mais pour cela il faudrait déplacer ton thread dans conception (? ou quelque part par là).
Enfin, un forum plus généraliste sur la POO.
merci d'ailleurs c'est là que j'aurai du posté cette question, mais les réponses obtenues m'ont éclairé
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager