Waarom je package-private scope in Java moet vermijden

Onlangs had ik het in mijn project over package-private visibility modifier.

“Wacht, wat is package-private in Java?” Het wordt ook wel eens default of no modifier genoemd.
Dit is wanneer een klasse of methode geen modifier heeft. Bijvoorbeeld:

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

Er staan meer details in de Java tutorial.

Het zou niet gebruikt moeten worden, tenzij er een zeer specifieke reden is. Je kunt kiezen tussen public, private of protected.

Er zijn redenen die ik tot nu toe van verschillende mensen heb gehoord:

• Maar ik heb het nodig om methodes in mijn object te testen!
• Maar het is beter om de toegang tot het Object zo veel mogelijk te beperken! Het wordt alleen benaderd door klassen uit hetzelfde pakket.
• Ik heb een bibliotheek met veel gebruikers en wil implementatiedetails voor hen verbergen!

Maar ik heb het nodig om methode in mijn object te testen!

Doe package-private niet alleen om die zeer belangrijke methode te testen. Het is een van de veel voorkomende denkfouten die ik zie. Mensen hebben de neiging om op de een of andere manier toegang te krijgen tot die prive-logica, het een beetje te versoepelen en dan vies te gaan testen!
Er is een betere manier. Eerst moet je begrijpen dat er waarschijnlijk iets mis is met je ontwerp, als er een verborgen functionaliteit is die moeilijk te testen is. Dat betekent dat het een perfecte kandidaat is voor refactoring! Verwerk die logica gewoon in een binnenklasse met goed gedefinieerde API methoden en test ze.

Maar het is beter om de toegang tot het Object zo veel mogelijk te beperken!

De officiële Oracle-documentatie zegt:
Use the most restrictive access level that makes sense for a particular member.
Use private unless you have a good reason not to.
Ik ben het helemaal eens met deze uitspraak, maar als we package-private uit deze lijst laten vallen. Het leven zal veel gemakkelijker zijn voor uw project als alles publiek/privaat zal zijn. Een van de meest voorkomende refactorings in grote codebases is Move File/Class. Met veel package-private toegang wordt het meteen vervelend om dat te doen. Waarom maak je ze dan niet public?
Op het einde stellen zowel public als package-private de API van je class bloot. Het maakt niet uit dat het in het laatste geval beperkt is door een package, het is nog steeds een API waar je om moet geven.

• Tests. Het is een relatief nieuwe trend om geen access modifiers voor testcode te schrijven. In ieder geval brengen modifiers wat ruis in de code en maakt de zichtbaarheid van toegang in tests niet zoveel uit als in productiecode. Minder typewerk is beter!
• Je ondersteunt een bibliotheek met veel gebruikers. Tenzij uw bibliotheek moet compatibel zijn met java8 of minder! Anders moedig ik aan om JPMS (Project Jigsaw) te gebruiken in je libs, dat geeft je veel betere controle over je blootgestelde API’s en interne implementatie in vergelijking met package-private

Dus zoals je kunt zien in 2019 (binnenkort 2020!) zijn er niet zo veel redenen om te gaan met package-private zichtbaarheid.