wie sollte man sinnvoll seinen Code aufteilen

[jCoder1984]

hallo zusammen

ich bin gerade dabei ein Tool mit Gui, Datenbankanbindung, Import und Export - Funktion zu schreiben. Wie ihr euch sicher denken könnt, wächst das Tool und auch der Code langsam. Ich habe mich zu Begin entschieden mit Maven die einzelen Teile (Importer, Exporter, Datenbank usw) in seperate Module zu verlagern. Nun bin ich mir aber nicht mehr sicher ob dieser Schritt richtig war bzw ob es einen besseren geben würde. Das Tool ist noch nicht fertig und es gäbe auch noch die Möglichkeit alles über den Haufen zu werfen. Daher meine Frage wie ein richtiger Weg wäre und was eure Erfharungen sind ?!

VIelen Dank für eure Unterstützung

 

[TomTank]

Wenn ich dich richtig verstehe suchst du das folgende:

Hier hat sich das sogenannte SOLID (S.O.L.I.D) - Prinzip von Robert Martin 1995 durchgesetzt.

(S)ingle Responsibility Principle / Prinzip der einfachen Verantwortung

• Jede Klasse sollte eine einzige Verantwortung haben.
• Es sollte nie mehr als einen Grund für eine Klasse geben.
• Klassen sollten klein sein. Nicht mehr als ein Bildschirm voller Code.
• Vermeiden Sie "Gott" -Klassen.
• Teilen Sie große Klassen in kleinere Klassen.

(O)pen/Close Prinzip / Offen/Geschlossen-Prinzip

• Ihre Klassen sollten zur Erweiterung geöffnet sein
• Aber für Änderungen geschlossen
• Sie sollten in der Lage sein, ein Klassenverhalten ohne es erweitern zu müssen zu modifizieren.
• Verwenden Sie private Variablen mit Getter und Setter - nur wenn du sie brauchst
• Verwenden Sie abstrakte Basisklassen

(L)iskov Subsitution Principle / Liskov-Subsidienprinzip

• Von Barbara Liskov, im Jahr 1998
• Objekte in einem Programm könnten durch Instanzen ersetzt werden ihrer Subtypen OHNE Änderung der Korrektheit der Programm.
• Verstöße scheitern oft am "ist ein" Test.
• Ein Quadrat "ist ein" Rechteck
• Allerdings ist ein Rechteck "Ist nicht" ein Quadrat

(I)nterface Segregation Principle / Trennprinzip der Schnittstelle

• Erstellen Sie feinkörnige Schnittstellen, die kundenspezifisch sind
• Viele kundenspezifische Schnittstellen sind besser als eine "allgemeine" Zweck "Schnittstelle
• Halten Sie Ihre Komponenten fokussiert und minimieren Sie sie Abhängigkeiten zwischen ihnen
• Beziehung zum Prinzip der einheitlichen Verantwortung beachten?
• Vermeiden Sie zB allwissende -Schnittstellen

(D)ependency Inversion Principle / Abhängigkeitsinversions-Prinzip
• Abstraktionen sollten nicht von Details abhängen
• Details sollten nicht von Abstraktionen abhängen
• Wichtig, dass Objekte auf höherer und unterer Ebene von derselben abstrakten Interaktion abhängen

 

[mrBrown]

* Ein Quadrat "ist ein" Rechteck
* Allerdings ist ein Rechteck "Ist nicht" ein Quadrat

Wo stammt dies denn her?
Ich wüsste nicht, wo eine Sub-Typ-Beziehung in beide Richtungen ein "ist ein" erfüllt - das wäre dann ja die selbe Klasse.

Daher meine Frage wie ein richtiger Weg wäre und was eure Erfharungen sind ?!

Ganz einfach formuliert: Zusammengehörende Dinge näher zusammen bringen und nicht zusammen gehörendes weiter trennen

Eigene Maven-Module machen dann Sinn, wenn die Dinge weit auseinander liegen und auch im wesentlichen unabhängig sind.
Ich würde besonders dann trennen, wenn es verschiedene Implementationen für einzelne Module geben kann oder wenn es sinnvoll ist, einzelne Dinge getrennt zu entwickeln, u.a. weil man dann getrennte Versionssprünge machen kann.

 

[TomTank]

Hi MrBrown,

dieses stammt aus Amerika, wie bereits geschrieben von Robert Martin 1995. Kurzversion ist auch im deutschen Wikipedia beschrieben. (Persönliche Meinung: Ich glaub, weil in Deutschland sowieso keine ernsthafte Softwareentwicklung betrieben wird, ist es wohl auf der deutschen Seite auch nur sehr rudimentär beschrieben). Auf der englischen Wikipedia https://en.wikipedia.org/wiki/SOLID ist es etwas besser beschrieben.

Zu

Wo stammt dies denn her?
Ich wüsste nicht, wo eine Sub-Typ-Beziehung in beide Richtungen ein "ist ein" erfüllt - das wäre dann ja die selbe Klasse.

s. https://en.wikipedia.org/wiki/Liskov_substitution_principle

 

[httpdigest]

(L)iskov Subsitution Principle / Liskov-Subsidienprinzip
• Ein Quadrat "ist ein" Rechteck
• Allerdings ist ein Rechteck "Ist nicht" ein Quadrat

Das Liskov Substitution Principle wird von Uncle Bob in seinen Vorträgen gerade dazu verwendet, zu zeigen, dass ein Quadrat eben KEIN Rechteck ist (was man aber leider intuitiverweise annehmen würde), weil das gerade gegen das beobachtbare Verhalten (bzw. die beobachtbare Eigenschaft) verstößt, dass man width und height unabhängig voneinander an einem Rechteck setzen könnte. Beispiel:

Rechteck r = new Quadrat();
// ...
// weiter unten Code, der nur Rechteck verwendet:
r.setWidth(20);
r.setHeight(30); // <- was nun?! Exception oder automatisch width auch auf 30 setzen, oder was?

Das LSP bezieht sich gerade eben auf die beweisbaren/beobachtbaren Eigenschaften/Verhalten einer Klasse und dieses Verhalten darf von Unterklassen NICHT verletzt/verändert werden, weil sie sonst nicht mehr semantische (im Gegenzug zu syntaktischen) Subtypen wären.

Und dieses Problem ist tatsächlich auf der Deutschen Wikipedia Seite sehr viel besser beschrieben, bzw. überhaupt erst erwähnt: https://de.wikipedia.org/wiki/Liskovsches_Substitutionsprinzip#Das_Problem

 

[mrBrown]

dieses stammt aus Amerika, wie bereits geschrieben von Robert Martin 1995. Kurzversion ist auch im deutschen Wikipedia beschrieben. (Persönliche Meinung: Ich glaub, weil in Deutschland sowieso keine ernsthafte Softwareentwicklung betrieben wird, ist es wohl auf der deutschen Seite auch nur sehr rudimentär beschrieben). Auf der englischen Wikipedia https://en.wikipedia.org/wiki/SOLID ist es etwas besser beschrieben.

Zu
s. https://en.wikipedia.org/wiki/Liskov_substitution_principle

Ich meinte nur die beiden von mir zitierte Beispiel. Das kommt eben ziemlich sicher so nicht von Uncle Bob, sondern ist ein ziemlich gutes Beispiel, wie LSP gebrochen wird

Auf den englischen Wikipedia-Seiten wird es, wie schon erwähnt, auch erst gar nicht erwähnt, sondern nur auf der (deutlich besseren) deutschen - da aber auch als Beispiel für Verletzung von LSP. Deshalb interessierte mich, wo dieses eine Beispiel her kommt.

Das "Allerdings" darin hab ich möglicherweise auch falsch verstanden...

 

[jCoder1984]

Euch allen vielen Dank für die vielen Hinweise - das hat mir sehr geholfen