cerhu > comp.* > comp.objet

Patrick Lamaizière (10/04/2010, 13h53)
YOUHOU Y'A QUELQU'UN ?

Bonjour,

Je regarde là des bonnes pratiques Java <http://www.javapractices.com>
et s'il y a des choses intéressantes, ils conseillent de déclarer les
champs en private.

C'est très fort de déclarer en private, puisque ça limite la
réutilisation d'une classe. Comment prédire la réutilisation éventuelle
d'une classe ? Je pense qu'il vaut mieux déclarer en protected.

Sans compter que plein de fois j'ai été bloqué en voulant réutiliser des
classes mais je n'ai pas pu en raison de champs private. Oui, mais moi
si je veux réutiliser ton truc hein ?

Qu'en dites vous ?
Wykaaa (10/04/2010, 20h36)
Patrick Lamaizière a écrit :
> YOUHOU Y'A QUELQU'UN ?
> Bonjour,
> Je regarde là des bonnes pratiques Java <http://www.javapractices.com>
> et s'il y a des choses intéressantes, ils conseillent de déclarer les
> champs en private.


C'est une bonne chose (voir plus bas)
> C'est très fort de déclarer en private, puisque ça limite la
> réutilisation d'une classe. Comment prédire la réutilisation éventuelle
> d'une classe ? Je pense qu'il vaut mieux déclarer en protected.
> Sans compter que plein de fois j'ai été bloqué en voulant réutiliser des
> classes mais je n'ai pas pu en raison de champs private. Oui, mais moi
> si je veux réutiliser ton truc hein ?
> Qu'en dites vous ?

Beaucoup de manuel qualité sur la programmation en C++ et Java
préconisent que les champs d'une classe soient toujours déclarés privés.
Ceci n'interdit pas la réutilisation si la classe est bien fichue, à
savoir, si elle contient des sélecteurs et, éventuellement des
modificateurs pour ces champs dans sa partie protégée (voire publique,
au moins pour certains sélecteurs).
Il faut bien voir que déclarer des champs "protected" induit un fort
couplage avec les sous-classes si celles-ci utilisent la représentation
du champ ou son nom directement. Donc, dans ce cas, ce sont les
sous-classes qui ne sont pas réutilisables telles quelles.

Je suis partisan d'une encapsulation maximale car j'ai vu trop de
"dégâts" dus à son manque : programmes difficiles à maintenir et,
surtout, à faire évoluer.

En Smalltalk il n'y a pas de "private" et "public". Les champs sont
toujours privés et les méthodes toujours publiques. Je trouve ceci peu
souple.
Bruno Desthuilliers (12/04/2010, 09h30)
Patrick Lamaizière a écrit :
> YOUHOU Y'A QUELQU'UN ?


Pas foule, apparament... Bienvenu sur f.c.objet, le newsgroup le plus
moribond de usenet.

> Bonjour,
> Je regarde là des bonnes pratiques Java


Dommage qu'on soit pas vendredi, y aurait déja matière à un beau troll
rien que sur ces trois derniers mots !-)

> <http://www.javapractices.com>
> et s'il y a des choses intéressantes, ils conseillent de déclarer les
> champs en private.
> C'est très fort de déclarer en private, puisque ça limite la
> réutilisation d'une classe. Comment prédire la réutilisation éventuelle
> d'une classe ?


Avec une boule de cristal ?

Effectivement, ce genre de prédiction peut s'avérer casse-gueule. Après,
il y a aussi des classes qui sont expressement conçues pour une
réutilisation (dans un framework par exemple).

> Je pense qu'il vaut mieux déclarer en protected.
> Sans compter que plein de fois j'ai été bloqué en voulant réutiliser des
> classes mais je n'ai pas pu en raison de champs private.


been here, done that...

> Oui, mais moi
> si je veux réutiliser ton truc hein ?
> Qu'en dites vous ?


Exactement le contraire de Wykaaa, comme d'hab !-)

En ce qui me concerne, forcer les restrictions d'accès au niveau du
language est une perte de temps et d'énergie, point barre. Une
convention (de nommage par example) précisant ce qui est API et ce qui
est implémentation (car c'est bien de ça, et uniquement de çà, qu'il
s'agit) est largement suffisante d'un point de vue pratique - et il
s'avère qu'en pratique, l'écrasante majorité des utilisateur d'un tel
système respectent cette convention tant qu'ils n'ont pas une raison
majeure de briser l'encapsulation. On gagne plus à faire appel à
l'intelligence des développeurs qu'en les prenant pour des neuneus.

Ceci étant, c'est aussi, bien sûr, et avant tout une question de
contexte - la réponse de Wykaaa fait probablement sens pour le type de
projets et d'organisation qu'il connait, qui sont à l'opposée de ce qui
constitue ma propre expérience. Besoins différents, contraintes
différentes, règles différentes...
Marc Boyer (12/04/2010, 12h40)
Le 10-04-2010, Patrick Lamaizière <adresse> a écrit :
> Bonjour,
> Je regarde là des bonnes pratiques Java <http://www.javapractices.com>
> et s'il y a des choses intéressantes, ils conseillent de déclarer les
> champs en private.
> C'est très fort de déclarer en private, puisque ça limite la
> réutilisation d'une classe. Comment prédire la réutilisation éventuelle
> d'une classe ? Je pense qu'il vaut mieux déclarer en protected.
> Sans compter que plein de fois j'ai été bloqué en voulant réutiliser des
> classes mais je n'ai pas pu en raison de champs private. Oui, mais moi
> si je veux réutiliser ton truc hein ?


Tu as tout dit "et si moi je veux réutiliser ton truc"...
Quelqu'un conçoit un code d'une façon, et quelqu'un veut le ré-utiliser
d'une autre. Qui a raison ? Impossible à dire de manière générale...

Après, j'ai tendance à croire que, de nos jours, la conception de
code se fait plus ou moins bien, mais que la maintenance est faite
n'importe comment (parce que c'est une activité qui ne jouis pas
d'une forte considération, que ça doit aller vite, et que personne
ne veut comprendre que pour aller modifier 10 lignes de code, il faut
savoir ce que les 100 lignes "autour" font, parce qu'on ne laisse
pas aux gens le temps d'écrire une doc de conception, etc).

Donc, j'ai tendance à dire qu'il faut réfléchir quand on conçoit,
laisser les attributs plutôt private, en se posant sérieusement
la questions des accesseurs. Définir un attribut privé sans
lui associer de methode "set*", c'est un choix qui devrait être
réfléchi.

M'enfin bon, il faudrait déjà avoir des invariants de classe,
des preconditions aux méthodes, etc.

Marc Boyer
Patrick Lamaizière (13/04/2010, 11h04)
Marc Boyer :

> Tu as tout dit "et si moi je veux réutiliser ton truc"...
> Quelqu'un conçoit un code d'une façon, et quelqu'un veut le ré-utiliser
> d'une autre. Qui a raison ? Impossible à dire de manière générale...


Pour moi par défaut c'est le gars qui veut qui réutiliser. Ça ne veut
pas dire que je vais (si j'en ai pas besoin) écrire une classe avec tout
ce qu'il faut pour l'hériter, mais je ne vais pas bloquer gratuitement
la réutilisation juste pour me faire plaisir.

> M'enfin bon, il faudrait déjà avoir des invariants de classe,
> des preconditions aux méthodes, etc.


Mon cheval pour du Dbc à la Eiffel. Java n'est pas très fun à ce niveau.
Patrick Lamaizière (13/04/2010, 11h06)
Bruno Desthuilliers :

> Patrick Lamaizière a écrit :
>> YOUHOU Y'A QUELQU'UN ?

> Pas foule, apparament... Bienvenu sur f.c.objet, le newsgroup le plus
> moribond de usenet.


Y'a encore des réponses... (merci)

> Exactement le contraire de Wykaaa, comme d'hab !-)
> En ce qui me concerne, forcer les restrictions d'accès au niveau du
> language est une perte de temps et d'énergie, point barre. Une
> convention (de nommage par example) précisant ce qui est API et ce qui
> est implémentation (car c'est bien de ça, et uniquement de çà, qu'il
> s'agit) est largement suffisante d'un point de vue pratique - et il
> s'avère qu'en pratique, l'écrasante majorité des utilisateur d'un tel
> système respectent cette convention tant qu'ils n'ont pas une raison
> majeure de briser l'encapsulation. On gagne plus à faire appel à
> l'intelligence des développeurs qu'en les prenant pour des neuneus.


Je suis assez d'accord.

> Ceci étant, c'est aussi, bien sûr, et avant tout une question de
> contexte - la réponse de Wykaaa fait probablement sens pour le type de
> projets et d'organisation qu'il connait, qui sont à l'opposée de ce qui
> constitue ma propre expérience. Besoins différents, contraintes
> différentes, règles différentes...


J'ai trouvé la réponse de Wykaaa assez pertinente. Si c'est fait comme
il faut et que des accès sont prévus aux champs private pourquoi pas.
Mais j'ai pas du voir ça souvent :-)
Bruno Desthuilliers (13/04/2010, 15h50)
Patrick Lamaizière a écrit :
(snip)

> Mon cheval pour du Dbc à la Eiffel. Java n'est pas très fun à ce niveau.


<troll mode="ce coup-ci je craque">
Pourquoi ? Java serait fun à d'autres niveaux et on ne m'en aurait rien
dit ?-)
</troll>

ok, je ---->[]
Patrick Lamaizière (13/04/2010, 20h15)
Bruno Desthuilliers :

> Patrick Lamaizière a écrit :
> (snip)
>> Mon cheval pour du Dbc à la Eiffel. Java n'est pas très fun à ce niveau.

> <troll mode="ce coup-ci je craque">
> Pourquoi ? Java serait fun à d'autres niveaux et on ne m'en aurait rien
> dit ?-)
> </troll>


Je ne trouve pas ça si mal, le langage est sans surprise et les outils
assez bien fait. C'est mieux qu'un Eiffel mort quelque part...
Wykaaa (13/04/2010, 22h34)
Patrick Lamaizière a écrit :
> Bruno Desthuilliers :
> Je ne trouve pas ça si mal, le langage est sans surprise et les outils
> assez bien fait. C'est mieux qu'un Eiffel mort quelque part...

Dommage car, de mon point de vue, Eiffel est un des meilleurs langages
objets mais les compilateurs n'ont jamais vraiment été au niveau...

Si seulement Java pouvait avoir le mécanisme de pré et post condition
d'Eiffel, on aurait fait un grand pas.

Pour Bruno (que je salue), mais aussi pour toi, Patrick, et sans vouloir
lancer une nième polémique (avec Bruno) :
J'ai enseigné Java (en entreprise pour des informaticiens, pas à des
étudiants). Plusieurs fois, assez nombreuses, des participants m'ont dit
que le langage leur donnait envie de l'utiliser. J'ai constaté moi-même
que j'avais plaisir à programmer en Java (bien plus qu'en C++ ou même en
ADA), en particulier les threads avec lesquels j'ai fait des choses
assez sophistiquées tel un programme qui pouvait lancer jusqu'à 200
threads avec des synchronisations dans tous les sens. Il n'a jamais
bogué et j'ai vérifié que, sur un certain laps de temps, tous les
threads créés avaient été exécutés (pas de "famine"). C'était au début
de Java et mon programme s'exécutait sous Windows 3.1 (!) qui n'était
pas multi tâches (c'est pour ça que j'avais programmé en Java, ça me
paraissait le plus facile pour mettre en oeuvre "mon usine à gaz" qui
simulait une machine multi processeurs, chaque thread étant un automate
fini communicant.
Cette expérience m'a réellement donné confiance dans Java. Cette
confiance n'a jamais été démentie (du moins avec les JVM sérieuses...).
Bruno Desthuilliers (14/04/2010, 10h28)
Wykaaa a écrit :
> Patrick Lamaizière a écrit :
> Dommage car, de mon point de vue, Eiffel est un des meilleurs langages
> objets mais les compilateurs n'ont jamais vraiment été au niveau...
> Si seulement Java pouvait avoir le mécanisme de pré et post condition
> d'Eiffel, on aurait fait un grand pas.


S'il pouvait aussi avoir un support décent pour les attributs calculés
et la délégation...

> Pour Bruno (que je salue), mais aussi pour toi, Patrick, et sans vouloir
> lancer une nième polémique (avec Bruno) :


Ah, m..., je suis déçu là !-)

Bon, je comprend qu'on puisse trouver Java plus abordable que C++ et
plus agile que ADA. Ca n'empêche pas nombre de développeurs Java de se
tourner maintenant vers des langages comme Ruby, Python, Scala etc...
Wykaaa (14/04/2010, 17h57)
Bruno Desthuilliers a écrit :
> Wykaaa a écrit :
> S'il pouvait aussi avoir un support décent pour les attributs calculés
> et la délégation...
>> Ah, m..., je suis déçu là !-)

> Bon, je comprend qu'on puisse trouver Java plus abordable que C++ et
> plus agile que ADA. Ca n'empêche pas nombre de développeurs Java de se
> tourner maintenant vers des langages comme Ruby, Python, Scala etc...

Un site intéressant (en anglais) bien que la méthode d'observation
puisse prêter à caution :
[..]
Bruno Desthuilliers (15/04/2010, 11h10)
Wykaaa a écrit :

> Un site intéressant (en anglais) bien que la méthode d'observation
> puisse prêter à caution :
> [..]


Wykaaa, je sais bien qu'à côté de toi je fais figure de petit jeune,
mais quand même... !-)
Wykaaa (15/04/2010, 12h09)
Bruno Desthuilliers a écrit :
> Wykaaa a écrit :
>> Un site intéressant (en anglais) bien que la méthode d'observation
>> puisse prêter à caution :
>> [..]

> Wykaaa, je sais bien qu'à côté de toi je fais figure de petit jeune,
> mais quand même... !-)

Même si peu de gens se manifestent sur ce forum, j'espère que nous ne
sommes pas que 3 ou 4 à le lire ;-)
Bruno Desthuilliers (15/04/2010, 15h05)
Wykaaa a écrit :
> Bruno Desthuilliers a écrit :
> Même si peu de gens se manifestent sur ce forum, j'espère que nous ne
> sommes pas que 3 ou 4 à le lire ;-)


Heu... t'es bien optimiste AMHA :(

Franchement, on pourrait aussi bien en faire un salon privé, vu
l'activité, ça passerait inaperçu.
Marc Boyer (16/04/2010, 09h52)
Le 13-04-2010, Patrick Lamaizière <adresse> a écrit :
> Marc Boyer :
> Pour moi par défaut c'est le gars qui veut qui réutiliser. Ça ne veut
> pas dire que je vais (si j'en ai pas besoin) écrire une classe avec tout
> ce qu'il faut pour l'hériter, mais je ne vais pas bloquer gratuitement
> la réutilisation juste pour me faire plaisir.


Ca dépend ce que tu appelles "bloquer gratuitement". Disons qu'à
mon sens, le pattern par défaut serait
attribut privé
set/get public ou protected suivant la sémantique

Après, ça se discute au cas par cas.

>> M'enfin bon, il faudrait déjà avoir des invariants de classe,
>> des preconditions aux méthodes, etc.

> Mon cheval pour du Dbc à la Eiffel. Java n'est pas très fun à ce niveau.


Ceci dit, ça pourrait déjà être dans les doc, voire instrumenté
à la main (avec une fonction protégée "bool inv()", et quelques
assert-like en début de code des méthodes...).

J'enseignais les invariants/preconditions en C, et ça aide
déjà pas mal.

Marc Boyer

Discussions similaires
Private Function Vs. Private Sub

DRM Protected !

Champs Actual Work Protected et Overtime Work Protected

Passer outre les protections private/protected


Fuseau horaire GMT +2. Il est actuellement 23h13. | Privacy Policy