Klassen & Paket Struktur

[Guest]

Guten Morgen allerseits!

Ich würde gerne einmal wissen wie Ihr in euren Java-Projekten die Klassen und Pakete Strukturiert, vor allem auch wenn das Projekt - das Programm immer mehr und mehr Klassen bekommt.

Lagert Ihr einzelne Klassen und Teile in eigene kleine Unter Projekte aus?
Sind eure Pakete so aufgebaut, dass Ihr Sie kopieren und in einem anderen Projekt verwenden könnt?
Baut Ihr eure Struktur auf nach dem Motto => meine TabellenModels liegen alle in einem Paket mit Namen "Model"?
etc. pp.

Wär schön mal von anderen zu hören wie Ihr eure Projekte Strukturiert.

Danke und Gruß
Markus

 

[ARadauer]

kann hier nur von mir sprechen:

Lagert Ihr einzelne Klassen und Teile in eigene kleine Unter Projekte aus?

eigentlich nicht

Sind eure Pakete so aufgebaut, dass Ihr Sie kopieren und in einem anderen Projekt verwenden könnt?

fast, ein bisschen muss man immer anpassen

Baut Ihr eure Struktur auf nach dem Motto => meine TabellenModels liegen alle in einem Paket mit Namen "Model"?
etc. pp.

ich gruppiere eher nach fachlicher thematik, was hab ich davon wenn ich meine 5 tablemodel besammen habe? wenn ich mein kundenTableModel bearbeite, ist es mir lieber wenn ich mein KundenDao und meinen Kunden gleich zur stelle habe... viele machens anders die gruppieren nach technischen aspekten, daos, gui usw.. aber von dem halte ich wenig...

 

[Puste]

Lagert Ihr einzelne Klassen und Teile in eigene kleine Unter Projekte aus?

Persönlich lagere Klassen/Pakete welche allgemeinen und nicht projektspezifischen Charakter haben immer in eine seperate lib aus. Dadurch hat man mit der Zeit einfach eine gewisse Basis an Modulen/Grundlagen welche man wiederverwenden kann. Es sei denn die Rahmenbedingungen verbieten mir dieses.
Dafür existiert quasi ein eigenes Projekt, um alle selbstentwickelten und wiederverwendbaren Klassen zu kapseln.

Sind eure Pakete so aufgebaut, dass Ihr Sie kopieren und in einem anderen Projekt verwenden könnt?

Ja, bzw. generiere ich mir dann eine Projektspezifische Library aus dem vorhandenen Pool, welche dann eingebunden wird.

Baut Ihr eure Struktur auf nach dem Motto => meine TabellenModels liegen alle in einem Paket mit Namen "Model"?

Sofern es ein allgemein gültiges Tabellenmodel ist, ja.
Ansonsten nach dem Grundsatz, so wenig Abhängigkeiten wie möglich zwischen verschiedenen Paketen. Es wird irgendwann recht unübersichtlich, wenn ein Bereich wie Usermanagement in unzähligen Paketen verstreut liegt.
Die oberste Trennung ist jedoch oft technisch.

 

[Puste]

Noch zwei drei Worte zu der obersten technischen Trennung.

Aus 2 Gründen bin ich für diese:
- Kompetenzen lassen sich besser verteilen, Porgrammierer nach technischen Fachbereichen aufzuteilen ist meiner Meinung nach weitaus sinniger, als nach rein modelthematischen. Also lieber jemanden an den DAOs basteln lassen, der sich damit auskennt, als alle ein wenig.

- Z.B. ein DAO sollte unabhängig vom Rest behandelt werden können. Wenn Änderungen in einem Bereich gemacht werden, dann sollte dies keine dramatischen Auswirkungen auf die anderen beiden Bereiche haben. Ob ein DAO nun verändert wird, was interessiert das die View?

 

[ARadauer]

Kompetenzen lassen sich besser verteilen, Porgrammierer nach technischen Fachbereichen aufzuteilen ist meiner Meinung nach weitaus sinniger, als nach rein modelthematischen. Also lieber jemanden an den DAOs basteln lassen, der sich damit auskennt, als alle ein wenig.

kommt wahrscheinlich auf die komplexität des programmes an, aber ich bin schon der meinung, dass der jenige der gerade die fachlogik schreibt, imstande sein sollte, den code für das dao zu schreiben... aber wie gesagt, kommt immer drauf an.

Ob ein DAO nun verändert wird, was interessiert das die View?

wenn ich zb jetzt nicht mit hibernate arbeite: ich füge meinem fachobjekt eine eigenschaft hinzu, änder hierfür mein model, meine view und mein dao... sehr häufiger case