Ah je suis bien content de voir que les attributs publics et final trouvent un intérêt !
Les attributs certes, mais l'article évoque tout un tas d'autres éléments importants qui peuvent être finalisés. Un code est clean, je pense, quand tous les éléments qui le composent ont la portée minimum qu'ils peuvent avoir. C'est vrai pour la portée au sens accessibilité (public, private, etc...) mais aussi pour la modifiabilité et l'extensibilté. Donc tout ce qui peut être final dans du Java devrait l'être, i.e.:
- Les attributs des classes qui sont invariants,
- Les variables locales qui ne sont pas réaffectées,
- Pour les paramètres de méthodes, la question ne se pose pas, il devraient toujours l'être,
- Les classes qui ne sont pas dérivées (i.e. si on veut être aussi rigoureux que possible, toutes les classes qui ne sont pas abstraites ; si, si, c'est toujours possible),
- Toutes les méthodes qui ne sont pas "Overridées".
Et, comme par un effet du hasard, les IDE peuvent souvent rajouter les mots clef final pour nous partout où c'est possible.
je "sentais" que lorsque un attribut était final il valait mieux le mettre directement en public au lieu de faire un getter
Ça, ça dépend des cas à mon sens. masquer des attributs peut avoir une signification sémantique. Mais quoi qu'il en soit, utiliser un getter pour lire un attribut final est effectivement inutile et contre-productif.
codemonkeyism.com ? Crénondidiou, ce site me pique les yeux de par les mauvaises pratiques qu'il propose
Pas tout à fait d'accord. Cet article propose quelques éléments méthodologiques tout à fait pertinents, à l'exclusion du point
2 qui est de nature à faire faire beaucoup trop d'opérations d'allocation inutiles. Le point
3 peut quand à lui être complété ; parcourir une liste en y appliquant un filtre, ça se fait en créant un itérateur sur celle-ci.
0 |
0 |
Envoyé par verbose
