Version imprimable
Ok donc a priori il me faut un cour objet. Donc suposons que tu as developper cette super classe et que moi qui suis moin bon que toi en objet je veuille la reutilisé.Citation:
Envoyé par natha
Mais je n'aime pas l'implementation de ton getter pour ta List.
Je ne veux plus faire de tests car je sais que ma variable est jamais null. Et j'ai besoin de performances
Donc je fais une sous class. Manque de pos tu as declare ta variable private je peux donc pas accede a ta variable ...
En gros tu as une idée fixe et rien ne te fera changer d'avis...
null peut avoir du sens, par exemple que je n'ai pas récupéré ces données en BDD. Si c'est null c'est que je dois faire un select, si c'est liste vide c'est que j'ai déjà fait un select (mais ça reste un exemple).Citation:
Sauf qu'avec null tu peux rien faire avec et tu auras surement des tests pour voir si ta variable est null ce qui est moche
Et puis si tu ne veux pas que ça soit null tu as qu'à l'initialiser dans le constructeur de ta sous-classe... Et comme je l'ai dit ici ce n'est qu'un exemple de l'utilité du getter.
En fait toi tu veux pouvoir faire n'importe quoi avec une classe qui n'a pas été conçue pour pouvoir être utilisée n'importe comment.Citation:
Donc je fais une sous class. Manque de pos tu as declare ta variable private je peux donc pas accede a ta variable ...
Tu peux accéder à ma variable via les accesseurs. Je dirais même plus : tu DOIS utiliser les accesseurs. Et l'argument des performances est ridicule car si tu n'as aucun listener sur l'objet, passer par les getters/setters est quasiment autant rapide que passer directement sur la variable. Si tu as vraiment besoin de performances pures tu n'utiliseras clairement pas des classes modélisées comme ça et on pourrait faire une exception au "tout private" mais toi tu dis que tu veux du "tout public" ce qui est une abération.
Bonjour,
Pour rebondir sur l'aspect "null", je suis également contre les instanciations systématiques car "null" est porteur d'information (comment je sais interpréter la même chose avec un objet instancié à la new MonObjet() mais finalement pas vraiment initialisé ?).
Pour en revenir au thème initial, il manque quelque chose d'important dans les dernières interventions, et je pense que c'est ca qui nous intéresse dans le "Private vs Protected" : les attributs d'un objet qu'il n'expose pas à "tout le monde".
En effet, si vous définissez des mutateurs publics (des vrais, pas ceux qui font plus que ce qu'on attend d'eux d'un point de vue extérieur), c'est finalement un faux problème puisque n'importe quel objet pourra modifier l'état de l'attribut, y compris les classes filles.
Par contre, pour un attribut qui n'est pas exposé directement (qui est modifié indirectement par des méthodes de type "ajouter" ou des méthodes métier), servant uniquement à l'état interne de l'objet, on en revient à la question du design, de la classe finale car non dérivable, ou de celle qui peut être sous-classée.
Eric
Une courte intervention sans rapport direct avec le sujet initial. Les accesseurs servent egalement a cacher l'implementation de cette meme propriete. Cette propriete peut etre :
- un membre d'instance de la classes private ou protected. Generalement dans ce cas il faut gerer les evenement manuellement.
- une valeur stockee dans un objet repository (voir PropertyChangeSupport ainsi que les methodes putClientProperty() et getClientProperty() dans les JComponent).
- etre delegee a un sous-objet dans le cas d'une composition complexe. En cas de gestion d'evenement, l'objet courant ecoute les proprietes de l'objet delegue et forwarde l'evenement en remplacant la source par lui-meme.
- a partir de Java 7 il devrait etre possible de specifier qu'un membre est une propriete (via une annotation je crois) et beneficier ainsi automatiquement d'accesseurs. Par contre je ne sais pas ce qu'il en sera de la propagation des evenements.
Les composants Swing utilisent un mix des 3 premieres solutions :
- les proprietes heritees ou similaires a celles de l'AWT sont souvent des membres.
- les proprietes plus recentes utilisent putClientProperty() et getClientProperty().
- les composants les plus complexes forwardent les proprietes de sous-composants auxquels ils deleguent le boulot en creant un nouvel evenement dont il sont la source (par exemple une surcharge des proprietes du UIDelegate ou du modele).
Salut,
Moi je met tout en private. Même si la classe est étendue.
Si j'ai besoin, je met un getter (public ou protected).
Salut,
On pourrait peut-être aussi considérer le problème sous un autre angle que celui de l'héritage de classe. Je pense que le fait de déclarer ses variables d'instance comme private, en fournissant des getter/setter, te permet aussi à toi développeur de pouvoir modifier par la suite l'implémentation de ta classe sans affecter d'autre code l'utilisant.
Supposons que j'ai une classe comme celle-ci :
Et si par la suite, pour une raison ou une autre (contrainte sur une base de données existante par exemple...), j'ai besoin que ma date soit stockée non plus comme une variable de type Date mais juste comme une variable de type long, je n'aurais qu'à réaliser la modification suivante dans ma classe :Code:
2
3
4
5
6
7
8
9
10
11
12
L'implémentation interne de la classe a changé mais pas son interface, donc les autres classes ne seront pas affectées puisqu'elles n'utilisent que les méthodes publiques prévues pour ça. Alors que si j'avais donné un accès public à cette variable, à coup sûr une telle modification aurait des conséquence désastreuses pour tout code qui utiliserait directement cette variable sous la forme instanceA.dateCode:
2
3
4
5
6
7
8
9
10
11
12
Bon, évidemment l'exemple que j'ai pris est un peu simpliste, mais il n'est pas rare de tomber sur des cas réels qui demandent de prendre de telles décisions.
Conclusion : Utiliser private autant que possible pour s'assurer non seulement la protection de son code, mais aussi la possibilité de pouvoir modifier son fonctionnement interne sans affecter ses classes clientes.
Excellente remarque. :king:Citation:
Envoyé par manblaizo
Je n'ai jamais dit tous public.Citation:
Envoyé par natha
:roll: les gens sont soit tous soit rien il n'arrive jamais a se poser et réfléchir 5min
Moi je suis plus pour protected.
Citation:
Envoyé par manblaizo
Dans ton exemple tu n'as pas besoin de private. protected suffit
Mais si quelqu'un a la mauvaise idée d'hériter de la classe, d'utiliser directement le champ. Et si un jour l'implémentation de la classe change, il risque d'y avoir un problème, alors qu'en mettant private avec un accesseur (accesseur qui peut faire autre chose que simplement donner la valeur), il n'y aurait pas eu ce soucis.Citation:
Envoyé par mathk
Je ne te confierais jamais un design d'application... :| :nono:Citation:
Envoyé par mathk
En fait tu as posé la question pour essayer de valider ce que tu fais déjà et même si tout le monde te dit et te démontre que ce n'est pas la meilleure chose à faire, tu restes bloqué sur ton truc...
Un petit point à ne pas oublier, c'est que la visibilité de protected ce ne sont pas que les classes dérivées, mais également le package...
En ce qui me concerne, j'ai retenu 2 arguments pour le private que je partage à 100% :
- Le besoin de faire des choses dans les setters. Le cas du propertyChange est vraiment typique. A noter que c'est quelquechose qu'on peut avoir besoin de rajouter après ! Si tu n'as pas conçu avec des getters/setters, c'est vraiment chiant à changer !
- Le besoin de changer l'implémentation interne sans conséquence pour l'extérieur : c'est tout de même le principe de base de l'encapsulation !!
En contre, j'ai retenu un seul argument, que je ne partage pas du tout : le côté pénible des setters/getters...
En 2007, avec les IDEs qu'on a, vous n'allez pas m'expliquer que c'est plus pénible à taper.
Quant à la lisibilité, c'est vraiment une pure question d'habitude ...
Donc pour moi, effectivement c'est tout private sauf bonne raison pour que ce ne soit pas le cas.
Reste la question effectivement des attributs qu'on ne voudrait pas exposer (donc pas de getter/setters publics). Pour moi dans ce cas il faut clairement distinguer deux cas différents :
- On est en train de développer une appli, et si besoin est ultérieurement on pourra changer la visibilité d'un getter/setter ou rajouter un getter/setter
- On est en train de développer une API. Ce cas est beaucoup plus complexe effectivement ! Car il faut vraiment réfléchir et imaginer les besoins futurs en termes d'héritage et de redéfinition ... Mais cela concerne pas plus d'1% d'entre nous :P
Concernant les question de design, je vais souvent m'inspirer du côté des sources de Sun, par exemple les implémentations de ArrayList AbstractList etc.
(Au passage, on peut comparer ces classes avec Vector, de conception plus ancienne, qui justement comportait des attributs protected.)
On se rend compte qu'il y a finalement assez souvent d'accès package, mais le plus souvent du private, ce qui tend à me faire pencher vers cette solution comme la meilleure.
Mais pour moi cette question concerne surtout celle des API (donc 1% des cas comme on disait) mais aussi du framework interne ou même de classes utilitaire au sein d'un projet.
De plus je me permet de glisser que je vois beaucoup de setter public, ce qui revient à appliquer la règle pour appliquer la règle, moi j'aurais plus tendance à éviter au maximum les setters public pour péférer du protected, faire très attention aux getters sur des types Collection Map ou List (qui permettent une modification du contenu sans contrôle)
Pour finir, sur des Classes "projet" d'objets métiers ou autre, je me suis trop souvent retouvé bloqué par la classe d'un autre qui était trop verrouillée pour imposer ça à mes petits copains, donc j'utilise encore pas mal l'accès protected sur les attributs de ce type de classe. En me disant qu 'au sein d'un projet, il est très facile d'utiliser le refactor pour déplacer du code, remplacer les variables par des getters etc... s'il faut.
Pour avoir vu des normes trop restrictives, je n'ai pas d'avis trop définitif sur ces définitions, il y a des grandes règles à appliquer, mais c'est une bonne conception objet qui prime, et cela, aucune norme ne peut l'imposer.
(edit précisions.)
de toute façon j'utilise un langage qui ne laisse pas le choix de la visibilité. De plus en Java il y a 4 niveaux de visibilité. Les choses sont toujours complexe en java. En lisant le code source de certaine application l'on s'en rend compte tres vite : (Argouml, Azureus, BlueJ...)Citation:
Envoyé par natha
Un langage qui peux être intéressant du point de vu de la visibilité serai celle Ruby (Juste pour le private)
Mon intention aura été juste de partager mon expérience car des attributs private pose toujours des problèmes pour le future