06
juin
2009
juin
2009
Java : les modificateurs de visibilité
Java / JEE ›
Articles
|
Tags :
java
Par Olivier Croisier
Si j'en crois les statistiques de Google Analytics, les modificateurs de visibilité sont un grand sujet d'interrogation parmi les développeurs Java, et reviennent régulièrement parmi les mots-clés menant au blog.
Voici donc un schéma récapitulatif (pdf et png) que vous pourrez imprimer et scotcher sur le côté de votre écran, les murs de votre bureau, ou dans les toilettes pour passer le temps de manière utile !
Attention, Java propose 4 niveaux de visibilité, mais seulement 3 mots-clés : private, protected, public ; la visibilité "package" est appliquée lorsqu'aucun mot-clé n'est utilisé[1].
Notes
[1] Ce système est à mon sens peu intuitif et discutable sur le plan de la conception objet.
Commentaires
Problème de ce schéma : il oublie un cas. Et ce cas est d'autant plus important que c'est une des grandes différences avec C+ + (et on va le voir, ce schéma n'est vraiment correct que pour C++, pas pour Java).
La différence concerne le mot-clé "protected".
En C++, un attribut ou une opération "protected" n'est accessible que par :
En Java, un attribut ou une opération "protected" n'est accessible que par :
Autrement dit, si dans le schéma ci-dessus, on ajoute une classe E dans le package 1, qui n'hérite pas de A (ou de B) :
Oups, comment ai-je pu oublier ce cas...
C'est maintenant corrigé, merci Hollydays !
Et la comparaison avec C++ est intéressante, j'ignorais cette différence.
Ben... je le sais parce que j'ai longtemps fait la même erreur ! Jusqu'au jour où j'ai été chargé de donner des formations sur Java.
Note : parmi les autres joyeusetés qui diffèrent entre C++ et Java, il y a le polymorphisme des opérations privées.
Vous savez sans doute qu'en C++, pour qu'une sous-classe puisse redéfinir l'implémentation d'une méthode, il faut déclarer explicitement celle-ci comme potentiellement polymorphe, avec le mot-clé "virtual". On qualifie alors la méthode de virtuelle (ce qui est, à mon avis, un contre-sens total : une méthode polymorphe est tout à fait réelle, tant qu'elle a une implémentation ; à se demander si Stroustrup, en créant C+ +, ne s'est pas mélangé les pinceaux entre polymorphe et abstrait. Mais bon, passons...)
Et bien, en C++, rien n'interdit de définir une opération privée comme étant virtuelle. Dans ce cas, une sous-classe peut redéfinir son implémentation, alors même qu'elle ne peut pas appeler l'implémentation de la classe mère ! Etonnant, non ? (je ne vous raconte pas les risques que cela pose en termes de maintenance du code lorsque le code de la classe mère invoque la fonction privée virtuelle...)
Tandis qu'en Java, comme vous le savez tous - ça ne fait aucun doute - une opération privée ne peut jamais être polymorphe (ce qui offre, à mon sens, une sécurité de programmation beaucoup plus grande). Quant aux autres opérations (publiques, protégées, package), elles sont toujours polymorphes, même lorsqu'il est explicitement déclaré que leur implémentation ne peut pas être redéfinie (avec le mot-clé "final").