Visibilités protégées et paquet-privé

Question

Y a-t-il une bonne raison pour laquelle le mot-clé protected permet d'accéder au champ/méthode du même paquet (de la même manière qu'aucun modificateur ne le permet)? Pourquoi la visibilité de package-private est-elle incluse dans le langage Java? À mon avis, il est contraire au principe d'encapsulation de permettre la modification d'un champ par une classe/méthode située dans le même paquet. Imaginez, je voudrais refactoriser le code et déplacer la classe à un autre paquet. Il casserait le code! Je considère ces deux visibilités comme une caractéristique obsolète et mal préparée du passé. Y at-il une raison de les utiliser ces jours-ci et en même temps empêcher le spaghetti blob?

Answer 1

La visibilité privée de paquet ne viole pas plus l'encapsulation que la visibilité privée, mais à un niveau différent: plutôt que de fonctionner au niveau classe par classe, la visibilité paquet-privée vous permet de contrôler l'encapsulation à le niveau paquet par paquet le plus grossier. Cela peut être important dans les situations où vous créez des classes auxiliaires qui doivent être visibles pour toutes les autres classes de votre module, mais ne doivent pas être visibles en dehors de celle-ci. Pour vous, l'auteur du module, de telles classes constituent un détail d'implémentation privé, donc si vous les déplacez dans un paquet différent, vous ne courez aucun risque de casser le code de quelqu'un d'autre; Seul votre code peut avoir besoin d'être refactorisé. D'autre part, la visibilité protégée contrôle l'accès le long des lignes d'héritage «verticales» (par opposition à la visibilité privée du paquet, qui est «horizontale»).

Answer 2

La visibilité des paquets fournit un accès plus restrictif que l'accès public. Cela vous permet d'exposer des parties de votre API uniquement à votre package, sans l'exposer au monde entier.

Pour les champs, la visibilité par défaut est la valeur par défaut des données non encapsulées. Cependant, pour les méthodes, la visibilité par défaut des paquets facilite l'utilisation de Java pour les débutants. Avoir une règle pour les deux réduit la complexité de la langue.

Answer 3

Absolument. La visibilité de paquet-privé est probablement le niveau de visibilité que j'utilise le plus souvent.

Les classes ne sont pas toujours la meilleure unité d'organisation. Dans de nombreux cas, vous concevez deux ou plusieurs classes qui fonctionnent étroitement ensemble. Ou vous avez une classe, mais elle devient si grande que vous voulez la diviser en plusieurs fichiers.

private accès est le moyen de cacher les détails de mise en œuvre au niveau de la classe, mais il peut encore être nécessaire (et raisonnable!) D'avoir paquet niveau détails de mise en œuvre que vous voulez toujours caché.

Answer 4

Surpris personne n'a mentionné TDD: sans package-private vous devrez utiliser protected, ce qui serait terrible, car vous exposeriez inutilement des charges d'internes à toutes les sous-classes.

TDD semble avoir été «inventé» après la création de Java, mais l'idée de tester des classes est évidemment antérieure à TDD. Je me demande si les concepteurs Java ont conçu package-private, précisément, à des fins de test?Les configurations actuelles sont plutôt élégantes parce que, comme tout TDD-er le sait, tant que la désignation de paquet de votre classe de test correspond à celle de la classe d'application testée, vous n'avez même pas besoin d'inclure vos classes de test dans la même structure de répertoires, qui a deux mérites: 1) vous n'avez pas à mélanger code d'application et code de test et 2) vous pouvez structurer votre code de test comme vous le souhaitez, par exemple structures de répertoires séparées pour tests unitaires, tests fonctionnels , les tests de bout en bout, etc.