# Größere Java-Projekte: Struktur



## Kababär (4. Mai 2017)

Hi,

ich wollte mal die Erfahrenen Benutzer fragen, wie man am besten größere Projekte strukturiert.
Mein Ziel ist es, einen "Planner" zu erstellen, der sich in 4 Bereiche aufteilen soll:

Universität (Semester und Module eintragen (mit vielen Details wie Note, Prüfungsdatum, Prüfer, Lehrender, Lerninhalte, Links zu Inhalten (sei es via web oder lokal), ...))
Finanzen: Verwaltung von Konten, "imaginäres" Überweisen zwischen Konten, Statisiken, ...
Arbeit: Übersicht über Stundenanzahl, Verdienst, Steuerabzüge, etc ...
Kalender: ähnlich wie Lightning bei Thunderbird. Termine können angelegt und gecancelled werden, "Mitglieder" können eingeladen werden via E-Mail. ICS-Dateien soll unterstützt werden.
So nun meine Frage. Bisher habe ich in src/main 5 packages:

main (da kommt alles rein, was für den Start und Preload zuständig ist. Des Weiteren kommen hier die Util-Klassen rein sowie alle sonstigen "Extras", die von mindestens zwei Bereichen gebraucht werden)
dann für jeden Bereich (siehe oben) ein weiteres Package.

Diese Struktur ist zwar relativ übersichtlich, aber wiederholt sich sehr oft, da ich für in jedem package nochmal die packages "model", "view" und "logic" habe.
Was ich mir überlegt habe:
Ich könnte jeden Bereich erstmal als "standalone" programmieren und dann via .dll einbinden.

Und da hört es auch schon auf mit meiner Kreativität. Auf jeden Fall finde ich die Idee mit den .dll gut, nur jetzt wo ich Maven kenne, kommt mir das relativ oldschool vor 

Habt ihr ein paar Tipps für mich? Würde mich freuen


----------



## Jardcore (4. Mai 2017)

Du solltest nicht mit Code spezifischen Elementen anfangen. (Packages usw.) Du musst die Software so planen, dass sie mit mehreren Sprachen umgesetzt werden kann. Fange am besten mit einer Anforderungsanalyse an und schaue anhand von einigen User Storys und Use-Case Szenarien was deine Software braucht.
Wenn du das hast, kannst du anfangen die Ergebnisse in UML zu gießen. Dann solltest du dir Gedanken machen um Sicherheit und Datenhaltung.

Das wäre ein Strukturierter Anfang.

Der hobbymäßige Anfang wäre. Programmiere drauf los und guck wo du hängen bleibst. Dann Refactor und beginne von Vorn.


----------



## Kababär (4. Mai 2017)

Ich denke mal die erste Variante bringt mich in Vielem weiter als die zweite Variante? 

Danke für die Hilfe!


----------



## stg (4. Mai 2017)

Jardcore hat gesagt.:


> Dann Refactor und beginne von Vorn.



Das hat dann aber nicht mehr viel mit Refactoring zu tun


----------



## Thallius (4. Mai 2017)

Warum erschlagt ihr eigentlich alle den, in meinen Augen, einzigen großen Vorteil den Java hat, nämlich seine Plattformunabhängigkeit indem ihr entweder irgendwelche dll nutzt oder aber gar wie hier selber welche erstellen wollt?

Was für einen Vorteil soll das denn bringen? Gerade bei einer Software wie sie der TO erstellen möchte ist es doch sehr einfach mit Java Plattform unabhägig zu programmieren und damit einen viel größeren Userkreis zu erreichen. Gerade auf einer Uni dürfte es sehr viele Mac und Linux Nutzer geben. 

Gruß

Claus


----------



## Kababär (4. Mai 2017)

Stimmt, viele haben Macs und immer mehr haben Linux-Laptops.

Aber Java ist doch generell plattformunabhängig, egal ob ich .dlls in ein Projekt packe oder nicht oder?
Ich sah den Vorteil darin, dass ich die Software modular gestalten kann, das heißt wenn ich nur den Kalender will, dann benutze ich auch nur den Kalender. Also so eine Art "Plugin"-Zusammenstellung.


----------



## thecain (4. Mai 2017)

Du weisst aber was eine dll ist? Ich glaube du meinst eher ein jar als dependency...


----------



## Kababär (4. Mai 2017)

Dynamic library oder nicht? Ich weiß, dass die meistens mit C oder C++ geschrieben werden.
Dachte mit Java wäre das auch möglich (mit Maven oder ähnlichem), aber deine Frage macht mich gerade etwas skeptisch 

Übrigens: Danke für deine Signatur


----------



## Jardcore (4. Mai 2017)

stg hat gesagt.:


> Das hat dann aber nicht mehr viel mit Refactoring zu tun


Muss ich das Sarkasmus Schild extra hochhalten?


----------



## mrBrown (4. Mai 2017)

Kababär hat gesagt.:


> Dynamic library oder nicht? Ich weiß, dass die meistens mit C oder C++ geschrieben werden.


Das ist soweit richtig - allerdings mit dem "Windows only"-Zusatz 

In Java entspricht das einfach einer jar


----------



## Kababär (4. Mai 2017)

mrBrown hat gesagt.:


> Das ist soweit richtig - allerdings mit dem "Windows only"-Zusatz
> 
> In Java entspricht das einfach einer jar


Aber doch nur, wenn ich Windows-spezifische Header-Dateien oder ähnliches include oder (oder generell vc++ benutze).

Dann mach ich mich mal an die Arbeit. Werde die ausführlichere Variante, die Jardcore vorgeschlagen hat, verwenden


----------



## mrBrown (4. Mai 2017)

Kababär hat gesagt.:


> Aber doch nur, wenn ich Windows-spezifische Header-Dateien oder ähnliches include oder (oder generell vc++ benutze).


Nein, dll ist das Windows-Format, zB Unixiode nutzen zB .so und macOS zusätzlich .dylib


----------



## mariane (4. Mai 2017)

Was heißt eigentlich "plattformunabhängig"?
Ist JAVA "plattformunabhängig"? <- unter Umständen nein (kann schon zw. Windows- und Unixwelt krachen, wenn nicht aufgepasst wird).
Ist jede andere Programmiersprache grundsätzlich "plattformunabhängig"? <- ja, solange keine Plattformabhängigen Funktionen genutzt werden, es braucht für die Zielplattform einen entsprechenden Compiler/Interpreter so wie es für JAVA die JRE auf der Zielplattform braucht.
Java hat lediglich einen Zwischenschritt mit seinem Bytecode. Meines Wissens kann man auch LUA, ist zwar eine Skriptsprache, in Bytecode vorcompilieren.


----------



## mrBrown (4. Mai 2017)

"plattformunabhängig" bezieht sich auf das kompilierte Programm, nicht nur auf den Source. In Java ist eine Jar zumindest auf jeder Plattform startbar, wenn es eine VM gibt. Eine exe wird aber nur unter Windows laufen. 

In Java muss man auch schon gegen die Konventionen programmieren, damit das nicht überall läuft, bei C ist ja durchaus nicht mal der Compiler austauschbar...


----------

