Porque deve evitar package-private scope em Java

Recentemente estava a discutir no meu projecto sobre o modificador de package-private visibility.

“Espere, o que é package-private em Java”? Também é por vezes chamado por defeito ou sem modificador.
É quando a classe ou método não tem nenhum modificador. Por exemplo:

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

Há mais detalhes no tutorial.

Não deve ser utilizado a menos que por uma razão muito específica. Pode escolher entre público, privado ou protegido.

Existem razões que ouvi até agora de pessoas diferentes:

• Mas preciso dele para testar o método no meu objecto!
• Mas é melhor restringir o acesso ao Objecto tanto quanto possível! Está a ser acedido apenas por classes do mesmo pacote.
• li> Tenho uma biblioteca com muitos utilizadores e quero esconder-lhes os detalhes de implementação!

Mas preciso dele para testar o método no meu objecto!

Não faça package-private apenas para testar esse método muito importante. É uma das falácias frequentes que observo. As pessoas tendem a ter de alguma forma acesso a essa lógica privada, apenas relaxar um pouco e depois fazer testes sujos!
Há uma maneira melhor. Primeiro é preciso compreender que algo provavelmente está errado com o seu design, se houver alguma funcionalidade oculta que seja difícil de conseguir testar. Isto significa que é um candidato perfeito para a refactoring! Basta extrair essa lógica para a classe interna com métodos API bem definidos e testá-los.

Mas é melhor restringir o acesso ao Objecto tanto quanto possível! Está a ser acedido apenas por classes do mesmo pacote.

Documentação oficial da Oracle diz:
Use the most restrictive access level that makes sense for a particular member.
Use private unless you have a good reason not to.br> Concordo totalmente com esta afirmação, apenas se retirarmos o pacote – privado desta lista. A vida será muito mais fácil para o seu projecto se tudo for público/privado. Um dos refactorings mais frequentes em grandes bases de código é Move File/Class. Com muitos pacotes de acesso privado, tornar-se-á imediatamente aborrecido fazê-lo. Porque não torná-los públicos então?
No final tanto público como privado exponha o API da sua classe. Não importa que no último caso seja limitado por pacote, continua a ser um API com o qual tem de se preocupar.

• Testes. É relativamente nova a tendência de não escrever modificadores de acesso para código de teste. De qualquer forma, os modificadores trazem algum ruído ao código e a visibilidade do acesso não importa tanto nos testes como no código de produção. Menos datilografia é melhor!

li>Você está a apoiar a biblioteca com muitos utilizadores. A menos que a sua biblioteca deva ser compatível com java8 ou menos! Caso contrário, encorajo a usar JPMS (Project Jigsaw) nas suas bibliotecas, o que lhe dará muito melhor controlo sobre as suas API’s expostas e implementação interna em comparação com o package-private

Então, como pode ver em 2019 (em breve em 2020!) não há tantas razões para preferir a visibilidade package-private.