Warum Sie den paketprivaten Bereich in Java vermeiden sollten

Kürzlich habe ich in meinem Projekt über den Sichtbarkeitsmodifikator paketprivat diskutiert.

„Moment, was ist paketprivat in Java?“ Es wird manchmal auch default oder no modifier genannt.
Das ist, wenn eine Klasse oder Methode keinen Modifikator hat. Zum Beispiel:

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

Es gibt mehr Details im Java-Tutorial.

Es sollte nicht verwendet werden, es sei denn, es gibt einen sehr speziellen Grund. Sie können entweder zwischen öffentlich, privat oder geschützt wählen.

Es gibt Gründe, die ich bisher von verschiedenen Leuten gehört habe:

• Aber ich brauche es, um Methoden in meinem Objekt zu testen!
• Aber es ist besser, den Zugriff auf das Objekt so weit wie möglich zu beschränken! Es wird nur von Klassen des gleichen Pakets zugegriffen.
• Ich habe eine Bibliothek mit vielen Benutzern und möchte Implementierungsdetails vor ihnen verstecken!

Aber ich brauche es, um eine Methode in meinem Objekt zu testen!

Nur um diese sehr wichtige Methode zu testen, sollten Sie nicht package-private verwenden. Das ist einer der häufigen Irrtümer, die ich beobachte. Die Leute neigen dazu, sich irgendwie Zugang zu dieser privaten Logik zu verschaffen, sie ein wenig zu lockern und dann schmutzige Tests durchzuführen!
Es gibt einen besseren Weg. Zuerst müssen Sie verstehen, dass wahrscheinlich etwas mit Ihrem Design nicht stimmt, wenn es eine versteckte Funktionalität gibt, die schwer zu testen ist. Das bedeutet, dass es ein perfekter Kandidat für ein Refactoring ist! Extrahieren Sie diese Logik einfach in eine innere Klasse mit wohldefinierten API-Methoden und testen Sie sie.

Aber es ist besser, den Zugriff auf das Objekt so weit wie möglich einzuschränken! Es wird nur von Klassen des gleichen Pakets zugegriffen.

Die offizielle Oracle-Dokumentation sagt:
Use the most restrictive access level that makes sense for a particular member.
Use private unless you have a good reason not to.
Ich stimme dieser Aussage voll und ganz zu, nur wenn wir package-private aus dieser Liste streichen. Das Leben wird viel einfacher für Ihr Projekt, wenn alles öffentlich/privat ist. Eines der häufigsten Refactorings in großen Codebases ist Move File/Class. Bei vielen paketprivaten Zugriffen wird es sofort lästig, dies zu tun. Warum dann nicht öffentlich machen?
Am Ende legen sowohl öffentlich als auch paket-privat die API Ihrer Klasse offen. Egal, dass sie im letzteren Fall durch das Paket eingeschränkt ist, es ist immer noch eine API, um die Sie sich kümmern müssen.

• Tests. Es ist ein relativ neuer Trend, keine Zugriffsmodifikatoren für Testcode zu schreiben. Immerhin bringen Modifier etwas Rauschen in den Code und die Sichtbarkeit von Zugriffen spielt in Tests nicht so eine große Rolle wie im Produktionscode. Weniger Typisierung ist besser!
• Sie unterstützen eine Bibliothek mit vielen Benutzern. Es sei denn, Ihre Bibliothek sollte mit java8 oder weniger kompatibel sein! Andernfalls empfehle ich Ihnen, JPMS (Project Jigsaw) in Ihren Bibliotheken zu verwenden, das Ihnen im Vergleich zu package-private

So wie Sie sehen können, gibt es 2019 (bald 2020!) nicht so viele Gründe, mit package-private Sichtbarkeit zu arbeiten.