Vous aimez ce que vous lisez sur ce blog ?
Envie d'aller plus loin avec véritable formation d'expertise en Java ?
Venez suivre ma formation Masterclasse Expertise Java !

"Même un développeur experimenté a besoin de continuer à apprendre. Et dans cette formation... j'ai appris beaucoup !" - A.G., Java Champion

Sessions intra-entreprises sur demande : contact[at]mokatech.net.
Inscrivez-vous vite !

Java : les modificateurs de visibilité

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 !


Java_visibility.png

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

1. Le dimanche 7 juin 2009, 01:15 par HollyDays

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 :

  • la classe A,
  • toutes les sous-classes de A.

En Java, un attribut ou une opération "protected" n'est accessible que par :

  • la classe A,
  • toutes les sous-classes de A, où qu'elles se trouvent
  • toutes les classes du même package que A, qu'elles héritent ou non de A.

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) :

  • En Java, "protectedField" sera accessible dans E.
  • En C++, il ne le sera pas.
2. Le dimanche 7 juin 2009, 01:54 par Olivier Croisier

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.

3. Le dimanche 7 juin 2009, 16:51 par HollyDays

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").

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.