Ich habe mir kürzlich eine Java-Anwendung angesehen, die eine sehr feinkörnige Paketstruktur hat. Viele Pakete enthielten nur eine oder zwei Klassen und viele Unterpakete. Außerdem enthielten viele Pakete mehr Unterpakete als tatsächliche Klassen.
Ist das eine gute oder eine schlechte Sache?
IMO, es ist eine schlechte Sache, obwohl nicht ein echter Show-Stopper in Bezug auf Wartbarkeit.
Die Nachteile bestehen darin, dass Klassen schwerer zu finden sind und die Paketnamen ausführlicher werden. Ersteres gilt mehr, wenn Sie keine IDE verwenden.
Es könnte argumentiert werden, dass es die Modularisierung in Verbindung mit "package private" Scoping unterstützt. Umgekehrt könnte man aber auch argumentieren, dass Überpaketierung tatsächlich das Gegenteil bewirkt; Sie müssen also public verwenden, wo Sie es nicht hätten tun müssen, wenn Sie weniger feingliedrig / pedantisch gewesen wären.
Die tatsächliche Anzahl der Typen, die in einem bestimmten Paket landen, ist nicht so wichtig. So kommen Sie zu Ihrer Paketstruktur.
Dinge wie Abstraktion ("was" anstelle von "wie", im Wesentlichen "öffentliche" API), Kopplung (der Grad der Abhängigkeit eines Pakets von anderen Paketen) und Kohäsion (wie hängt die Funktionalität in einem Paket zusammen) wichtiger.
Einige Richtlinien für das Verpackungsdesign (hauptsächlich von Onkel Bob ) sind zum Beispiel:
Versuchen Sie nicht, die gesamte Paketstruktur von Grund auf neu zu gestalten (Sie werden es nicht brauchen). Stattdessen lass es sich weiterentwickeln und oft umgestalten. Sehen Sie sich den Abschnitt import Ihrer Java-Quellen an, um sich über bewegte Typen zu informieren. Lassen Sie sich nicht von Paketen ablenken, die nur einen oder wenige Typen enthalten.
Ich denke, eine feinkörnigere Paketstruktur ist eine gute Sache. Der Hauptgrund ist, dass es helfen kann, Ihre Abhängigkeiten zu minimieren. Aber seien Sie vorsichtig ... wenn Sie Dinge zu sehr trennen, die eigentlich zusammengehören, werden Sie mit zirkulären Abhängigkeiten enden!
Als Faustregel habe ich normalerweise eine Schnittstelle (oder eine Gruppe verwandter Schnittstellen) in einem Paket. Und in Unterpaketen werde ich Implementierungen dieser Schnittstellen haben (anstatt alle Implementierungen im selben Paket zu haben). Auf diese Weise kann ein Client nur auf die Schnittstelle und die Implementierung von Interesse angewiesen sein ... und nicht auf all die anderen Dinge, die sie nicht brauchen.
Hoffe, das hilft.
Es ist natürlich subjektiv, aber im Allgemeinen bevorzuge ich, meine Pakete so zu entscheiden, dass sie mindestens 3-4 Klassen enthalten, aber nicht mehr als etwa 13-15. Es macht das Verständnis besser, ohne das Projekt zu überladen. Für andere könnte es jedoch anders sein. Wenn ein Paket mehr als 13-15 Klassen anwächst, fordert ein Unterpaket auf zu erscheinen.
Ein Paket ist eine Kapselungseinheit.
Idealerweise stellt es eine öffentliche API über Schnittstellen zur Verfügung und verbirgt Implementierungsdetails in privaten Paketklassen.
Die Größe des Pakets ist daher die Anzahl der Klassen, die zum Implementieren der öffentlichen API benötigt werden.
Es gibt auch die magische Zahl 7 +/- 2. In physiologischen Kreisen hat sich gezeigt, dass dies eine grundlegende Grenze für unsere Fähigkeit ist, eine gegebene Menge von Dingen zu verstehen. Wie viel können wir im Kurzzeitgedächtnis behalten und gleichzeitig verarbeiten, bevor unser Gehirn anfangen muss, zu tauschen. Es ist keine schlechte Faustregel, die ich beim Codieren gefunden habe, dh sobald ein Paket größer als 10 Klassen wird, ist es an der Zeit, ernsthaft darüber nachzudenken, es aufzuteilen, aber unter 5 Paketen ist es das wirklich nicht wert. Gilt auch gut für Dinge wie Menü-Organisation. Siehe Millers Papier oder google.
Wenn ich von Grund auf schreibe, ist mein Weg, alle Klassen im root-Paket (com.example.app1) zu beginnen. Wenn es eine bestimmte Anzahl zusammenhängender Klassen gibt, die "eine ganze Sache machen", ist es Zeit, ein Paket zu erstellen. Nach einiger Zeit können Entwicklungshelferklassen zu einem generischen Paket (z. B. com.example.app1.misc, com.example.app1.utils) wechseln, um das root-Paket zu entfernen.
Also versuche ich das Root-Paket sauber zu halten.
Feinkörnig ist nicht schlecht, aber wie andere gesagt oft Refactoring produzieren eine kompakte Paketstruktur.
Tags und Links java