Liegt hier bereits ein Bad Smell vor?

[Maik.Neumann]

Guten Tach !

Ich habe derzeit mit einem Projekt in Java (genauer gesagt Maven) zu tun, dass aus drei verschiedenen Maven Projekten besteht, wobei eines davon eine Art Anwendungskern darstellt, eines ist speziell für GUI Seiten (JSF) und das letzte händelt so ein bisschen das Zusammenspiel zwischen GUIs und den Klassen, die direkt hinter diesen GUIs stehen (JSF Beans).

Nun ist es leider so, dass die einzelnen Klassen dieser Projekt sich fast vollständig gegenseitig kennen und somit harte Abhängigkeiten (Projektübergreifend und auch Paketübergreifend) vorhanden sind.

Meine Frage an euch (auh wenn es eine sehr allgemeine Frage ist): Ist diese Art von Projektaufteilung schon im Vorraus irgendwann zum Scheitern verurteilt? Sind solche gegenseitigen "Bekanntschaften" von Klassen aus unterschiedlichen Paketen und Maven Projekten bereits schon eine Art Bad Smell und wenn ja, wie kann man so etwas versuchen zu entkoppeln? Evtl. nur über die Definition von Schnittstellen?

 

[ceving]

Was ist eine harte Abhängigkeit? Ich kenne nur public, package local, protected und private.

 

[Sogomn]

Was ist eine harte Abhängigkeit? Ich kenne nur public, package local, protected und private.

Er redet von fester Kopplung, glaube ich.

Ich kenne deinen Code nun natürlich nicht - mit Maven hab' ich auch noch nichts zu tun gehabt - aber ich hatte dasselbe Problem bei einem anderen Projekt. Ich denke, deine Idee, mit Interfaces zu arbeiten, ist gut.

 

[Bug Fisher]

1. Frage: ja warum kennen sich denn fast alle Klassen gegenseitig ? Ich meine, warum hast du das überhaupt so gebaut ? Wenn das notwendig ist, wären ganz klar Zuständigkeiten vermischt, die bei einzelnen Klassen klarer aufgeteilt sein sollten.
Also Assoziationen sind standard und ohne gibt es kein größeres Projekt, aber das klingt so, als hättest du eine Art eingetretenen Weg, allen Klassen erstmal alle anderen mitzugeben... muss das sein ?

 

[nvidia]

[...] wie kann man so etwas versuchen zu entkoppeln? Evtl. nur über die Definition von Schnittstellen?

So viele Möglichkeiten gibt es da nicht, eine wäre z.B. sich auf OSGI zu stützen aber wenn man begriffen hat was dort eigentlich passiert kann man das auch mit Selbstbeherrschung und dependency injection Frameworks hinbekommen.

Eine art live-Coding-Session auf OSGi-Basis und Gedanken zu Modularität findet man z.B. hier https://www.parleys.com/play/543f9312e4b08dc7823e549a/about.

 

[ceving]

Er redet von fester Kopplung, glaube ich.

"Feste Kopplung" gibt es in der Oracle-Doku von Java auch nicht.

 

[Ruzmanz]

Die Aufteilung klingt wie eine Schichtenarchitektur. Wenn dessen Prinzipen eingehalten werden ist die Architektur in einem guten Zustand. Es sollten auf keinen Fall eine zyklischen Abhängigkeit zwischen den Projekten vorhanden sein.

Bei Interfaces gibt es verschiedene Strategien. In deinem Fall würde ich vorschlagen, dass alles so bleibt wie es ist. Eine Implementierung == Kein Interface. Wenn das Projekt wächst, kann man die Klasse kopieren und den Namen ändern. Zum Beispiel von "User" in "StandardUser". Die Klasse "User" wird zum neuen Interface. Dann kannst du mit suchen und ersetzen jede Stelle im Quellcode von "new User()" auf "new StandardUser()" ändern. Anschließend erstellst du dir deine neue Klasse "PrivilegedUser" und implementierst diese ...

Wie man das aufteilt ist vom Prinzip her egal. Ich habe auch schon Software gesehen, wo jede Schicht in einem eigenen Projekt abgelegt wurde. Ob das nun ein Package oder Projekt ist spielt i.d.R. kaum eine Rolle. Der Hintergedanke ist, dass man das GUI-Projekt irgendwann wegwerfen könnte, um von SWT auf XYZ zu wechseln. D.h. die anderen Projekte dürfen zwar aktuell auf die Daten des GUI-Projekts zugreifen, aber keine SWT spezifischen Dinge implementieren / nutzen. Wenn du jetzt sagst, dass ihr ein Projekt "speziell für GUI Seiten" habt, dann darf im Anwendungskern keine Abhängigkeit zu JFace bestehen.

 

[ARadauer]

dass die einzelnen Klassen dieser Projekt sich fast vollständig gegenseitig kennen

Gib mir mal ein Beispiel. Grundsätzlich sollte man das vermeiden

 

[ARadauer]

"Feste Kopplung" gibt es in der Oracle-Doku von Java auch nicht.

es gibt mehr dinge, die dir als entwickler ein begriff sein sollen, die aber nicht in der oracle-doku stehen....

 

[Sogomn]

"Feste Kopplung" gibt es in der Oracle-Doku von Java auch nicht.

Hat auch recht wenig mit Java an sich zu tun. Hängt mit objektorientiertem Design zusammen.