Projektaufbau

[osion]

Hallo

Ich habe sehr grosse mühe mit einem Projektaufbau, d. h. Ordnerstruktur, Dateien richtig benennen.
Mir ist nie bewusst ob ich einen Interface Ordner machen soll oder wenn man wenige Dateien hat die alle in einen Ordner (z. B. bei Main->PluginA oder ->PluginA->interfaces).

Wie geht ihr hier vor? Was sind die Norm? Gibt es gute Bücher oder eine Webseite?

 

[mihe7]

Die Fachlichkeit steht für mich im Vordergrund. Wenn ich mir die Paketstruktur ansehe, möchte ich sofort (d. h. nach einem allgemeinen Package-Prefix wie org.javaforum.mihe7.<projekt>) erkennen, worum es in der Anwendung geht und in welchem Paket ich welche Fachlichkeit finde.

Manche gehen her und zeigen erstmal die grundlegende Architektur der Anwendung. Da findet man dann so absolut uninteressante Dinge wie model, view, controller (oder eben auch interfaces). Um welche Anwendung es sich handelt, kann hier kein Mensch sagen. Wenn man dort die Fachlichkeiten sieht wie z. B. customer, invoice usw. dann weiß man sofort: aha, hier gehts um Kunden, dort um Rechnungen.

Darunter ist man wiederum flexibel. Da kann model, view, controller Sinn machen. Man kann sich am Domain Driven Design orientieren und findet dann etwa repository, entity, service oder man nimmt sich das boundary-control-entity Pattern vor. Das merkt man mit der Zeit schon, was am besten zum Projekt passt (das ist weder in Stein gemeißelt noch spielt es eine herausragende Rolle).

Die Benennung der Dateien ist wesentlich einfacher, weil die zwangsweise so heißen müssen wie der darin auf dem top-level definierte Typ.

Soviel zu meiner Meinung, mal schauen, was andere sagen

 

[kneitzel]

Erst einmal stimme ich @mihe7 prinzipiell zu, aber ich würde da noch ein wenig eingrenzen:

a) Aufteilung macht nur Sinn, wo man wirklich etwas aufteilen muss. Wenn jede Klasse plötzlich ihren eigenen Namespace hat, dann war es wohl etwas zu viel des Guten Also Namespaces mit nur eine Klasse "riechen". Das ist zumindest meine Sichtweise.

b) neben der fachlichen Untergliederung in einem Projekt muss man aber auch sehen, dass es eine Unterteilung in mehrere Projekte geben kann. Das steht dann zwangsläufig über der fachlichen Trennung.

Generell sollte man "natürliche Grenzen" wählen. Also nicht auf krampf irgendwas zusammen packen oder trennen. Also wirklich von der fachlichen Seite überlegen: Was gehört wie zusammen? Wie hängen dann die Blöcke zusammen? Da sieht man dann schnell, was zusammen gehört und was nicht.

Und wie @mihe7 schon deutlich gemacht hat: Es gibt mehrere Möglichkeiten. Daher gibt es da auch nicht wirklich ein richtig oder falsch. Im Worst case merkt man, dass es nicht wirklich passt und dann strukturiert man etwas um. Das habe ich aber irgendwie noch nie im Großen erlebt - dass also eine Struktur grundlegend geändert wurde. Im kleinen natürlich ständig: Ein Teil wächst und schon wir der aufgeteilt oder so. Meine Erfahrung ist, dass man in der Regel ein Team ein "bevorzugtes Pattern" hat und danach wird meist vorgegangen.

 

[M.L.]

Und zusätzlich: https://www.java-forum.org/thema/wi...vernuenftige-klassen-ein.185926/#post-1197005

 

[White_Fox]

Oft ergibt sich eine logische Zusammensetzung schon von alleine. Nehmen wir an, du realisierst irgendeine Funktionalität mit drei oder vier Klassen, die alle sehr eng zusammengehören. Man könnte jetzt jede Menge Unsinn veranstalten, wenn alle nichtprivaten Methoden der Klassen projektweit öffentlich sind. Es muß noch nichtmal böse Absicht dahinter stecken, es reicht ja schon daß ein riesiger Methodenzoo verwirrend ist und die Übersicht leidet.
Daraus alleine ergibt sich dann schon, daß die Klassen in ein package sollten und die Methoden, die nur für die Klassen untereinander bestimmt sind, sollten packageprivate bleiben.

Mein Projekt ist nur eine Einmannshow, trotzdem arbeite gerne sehr restriktiv und vermeide es tunlichst, mehr öffentlich sichtbar zu machen als unbedingt notwendig.
Vieles baue ich dabei so, daß ich es in einem anderen Projekt wiederverwenden könnte, wenn ich wollte. Dabei steht (zumindest heute, früher war das auch mal anders) aber mittlerweile weniger die Wiederverwendung im Vordergrund, sondern man ist angehalten ein Problem möglichst stark zu abstrahieren und eine eindeutige Schnittstelle zu definieren, die keinerlei Bezug zur konkreten Anwendung enthält. Natürlich kommt so eine Pseudobibliothek in ein eigenes Paket.
Der Vorteil dabei ist, daß sehr viele Änderungen oder Erweiterungen nicht gleich dein komplettes Projekt betreffen, sondern sich oft auf ein einziges Paket beschränken.

 

[Mart]

Wenn jede Klasse plötzlich ihren eigenen Namespace hat

was sind Namespaces denn genau?
ich hab schon bei c# zb gesehen dass man um eine klasse herum einen Namespace benennen kann aber hab nie herausgefunden was das denn sein sollte

 

[kneitzel]

Wenn ich es Umgangssprachlich ausdrücken müsste, dann wäre ein Namespace nur eine Gruppierung von Klassen / Interfaces.

Dies gewinnt dann bei Zugriffsrechten (package private) und bei Modulen Bedeutung.

Wenn man in der JLS nachsehen will, dann ist da namespace natürlich nicht definiert. Da ist bei mir meine c# Vergangenheit hervor gekommen. Dort findet man Package. Das ist aber auch das, was ich gemeint habe.

 

[mihe7]

Wenn jede Klasse plötzlich ihren eigenen Namespace hat

was sind Namespaces denn genau?
ich hab schon bei c# zb gesehen dass man um eine klasse herum einen Namespace benennen kann aber hab nie herausgefunden was das denn sein sollte

Ein Namespace ist genau das: ein Namensraum. Namensräume dienen dazu, Konflikte zu vermeiden.

Wenn Du z. B. eine Klasse a.b.c.Klasse1 hast mit einer main-Methode und eine Klasse a.b.c.Klasse2, die ebenfalls eine main-Methode besitzt, dann funktioniert das, weil a.b.c.Klasse1 und a.b.c.Klasse2 unterschiedliche Namensräume für die main-Methoden darstellen.

Noch logischer wird es, wenn Du an Bibliotheken denkst. Hast Du zwei Bibliotheken, die jeweils die Klasse StringUtils definieren, dann würde das bei Verwendung beider Bibliotheken zu einem Konflikt führen. Durch unterschiedliche Namensräume (die in Java mit Hilfe von Paketen realisiert werden) kann das Problem umgangen werden.

 

[Barista]

In Java muss das Package (Namensraum) mit dem Verzeichnis, in welchem die Datei ist, übereinstimmen.

Dabei ist das Verzeichnis relativ zum Quellcode-Verzeichnis (source folder) gemeint.

In anderen Sprachen (C#, C++, Scala) ist dies anders (aber im Einzelnen und wirklich exakt weiss ich das nicht).