Re: Konventionen für eigene Packagewahl

Responding to Norbert Melzer:

>>> Und vor allem wie geht es danach weiter? Dann Teilen in App und Lib? Oder
>>> lieber die Libs mit in die gleichen Packages wie die Applikation?
>>
>> So wie du möchtest.
>
> Welches der Vorgehen hat sich denn hier in der Praxis bewährt? Ich würde
da
> jetzt Angesichts der wiederverwendbarkeit von Code wohl eher auf getrennte
> Apps und Libs Packages tippen, oder liege ich da falsch?

Libraries, die man ggfs. in ein separates Jar packen und in gaenzlich
anderem Kontext wiederverwenden moechte, gehoeren IMO in eigenstaendige
Projekte (dann natuerlich auch mit eigenstaendiger Packagestruktur).

Innerhalb eines Library- oder Applikationsprojekts sollten sich
"natuerliche" Grenzen fuer Packages finden lassen, beispielsweise:

- Funktionalitaet unterschiedlicher Layers (Persistenz, Domaenenlogik,
UI,...) gehoert in separate Packages.
- Ein "Cluster" von Implementierungsklassen fuer eine bestimmte API/ein
bestimmtes Interface gehoert in ein eigenstaendiges Package.
- Unterschiedliche, polymorphe Implementierungen einer abstrakten
Funktionalitaet gehoeren jeweils in separate Packages.
- ...

Robert Martin hat einige Daumenregeln zur Package-Granularitaet
zusammengestellt, siehe "Common Reuse Principle", "Common Closure
Principle", "Acyclic Dependencies Principle", "Dependency Inversion
Principle",...

Die IMO wichtigste (und auch toolbasiert, etwa mit JDepend,
ueberpruefbare) Grundregel ist die Vermeidung von Zyklen zwischen
Packages. Die Aufloesung eines Zyklus sollte ueblicherweise nicht durch
das blinde Zusammenfuehren der beteiligten Packages geschehen, sondern
indem man die beteiligten Klassen (ggfs. unter Einfuehrung neuer
Packages) solange jongliert, bis sie von ihrer Funktionalitaet her
besser zusammenliegen - die Klassen dahin bringt, "wo sie hinwollen".
Meiner subjektiven Erfahrung nach kann das sehr helfen, zu einem
stabileren und besser wartbaren Design zu gelangen.

Schlussendlich ist die Packageaufteilung aber immer, wie von Tor bereits
angedeutet, eine subjektive Sache, die stark vom konkreten Projekt (und
nicht zuletzt eventuell auch teamspezifischen Konventionen) abhaengt.

Viele Gruesse,
Patrick
[ Auf dieses Posting antworten ]