Pourquoi vous devriez éviter le scope package-private en Java

class SomeObject { void doSomething() { ... }}

Il y a plus de détails dans le tutoriel Java.

Il ne devrait pas être utilisé à moins d’une raison très-très spécifique. Vous avez le choix entre public, privé ou protégé.

Il y a des raisons que j’ai entendues jusqu’à présent de la part de différentes personnes :

• Mais j’en ai besoin pour tester la méthode dans mon objet !
• Mais il vaut mieux restreindre l’accès à l’Objet autant que possible ! Il n’est accédé que par des classes de même package.
• J’ai une bibliothèque avec beaucoup d’utilisateurs et je veux leur cacher les détails d’implémentation!

Mais j’en ai besoin pour tester une méthode dans mon objet!

Ne faites pas de package-private juste pour tester cette méthode très importante. C’est l’un des sophismes fréquents que j’observe. Les gens ont tendance à avoir en quelque sorte accès à cette logique privée, à la détendre un peu et ensuite à faire des tests sales !
Il y a une meilleure façon. Tout d’abord, vous devez comprendre que quelque chose probablement mal dans votre conception, s’il y a une certaine fonctionnalité cachée qui est difficile à obtenir à tester. Cela signifie que c’est un candidat parfait pour le refactoring ! Il suffit d’extraire cette logique dans une classe interne avec des méthodes API bien définies et de les tester.

Mais il est préférable de restreindre l’accès à l’objet autant que possible ! Il n’est accédé que par des classes de même package.

La documentation officielle d’Oracle dit:
Use the most restrictive access level that makes sense for a particular member.
Use private unless you have a good reason not to.
Je suis totalement d’accord avec cette déclaration, juste si nous allons laisser tomber package-private de cette liste. La vie sera beaucoup plus facile pour votre projet si tout est public/privé. L’un des remaniements les plus fréquents dans les grandes bases de code est Move File/Class. Avec beaucoup de paquets d’accès privés, il deviendra immédiatement ennuyeux de le faire. Pourquoi ne pas les rendre publics alors ?
A la fin, les deux, public et package-private, exposent l’API de votre classe. Peu importe que dans ce dernier cas, elle soit limitée par le paquet, c’est toujours une API dont vous devez vous soucier.

• Tests. C’est une tendance relativement nouvelle de ne pas écrire de modificateurs d’accès pour le code de test. De toute façon les modificateurs apportent un peu de bruit au code et la visibilité d’accès n’a pas autant d’importance dans les tests que dans le code de production. Moins de typage, c’est mieux !
• Vous soutenez une bibliothèque avec beaucoup d’utilisateurs. Sauf si votre bibliothèque doit être compatible avec java8 ou moins ! Sinon, j’encourage à utiliser JPMS (Project Jigsaw) dans vos librairies, ce qui vous donnera un bien meilleur contrôle sur vos API exposées et votre implémentation interne par rapport à package-private

Donc, comme vous pouvez le voir en 2019 (bientôt 2020 !), il n’y a pas tant de raisons d’aller avec la visibilité de package-private.