Design Patterns für Programm

geneticZ

Bekanntes Mitglied
Hallo,
ich habe hier für meine Begriffe ein etwas größeres Projekt und würde gerne einen sauberen und übersichtlichen Programmcode dafür schreiben. Kurz zur Erklärung: Ein bereits bestehendes Datenbankprojekt mit einer enormen Anzahl an Datensätzen muss in ein komplett neues und angepasstes Datenbanksystem umgesetzt werden. Hierfür werden die Datensätze in XML exportiert und mit Java in die neue Umgebung / Datenbank implementiert.

Soweit so gut, das alles ist auch kein all zu großes Problem, aber ich möchte eben einen sauberen Code haben.

Im neuen Datenbanksystem gibt es ca. 15 verschiedene Tabellen und ich hatte bis jetzt vor, für jede in Java eine eigene Klasse anzulegen. Dies bringt mich zu der Annahme dass in diversen Fällen Operationen redundant sein könnten oder immer auf die gleichen Werte zurückgreifen müssen.

Was derzeit der Fall ist aber höchstwahrscheinlich besser oder sauberer gemacht werden kann:
- Alle Klassen bekommen den selben XML-Knoten im Konstruktor übergeben von dem die Werte ausgelesen werden.
- Alle Klassen bekommen den selben XML-Namespace im Konstruktor übergeben
- Alle Klassen bekommen das selbe Objekt einer Klasse übergeben die Operationen an der Datenbank durchführt (z.B. DBconnection, preparedStatements)
- Alle Klassen haben aber auch unterschiedliche Methoden! Vor allem der Algorithmus für das Auslesen der XML-Tags besteht zwar immer, ist aber bei jeder Klasse unterschiedlich.

Irgendwie habe ich das Gefühl dass hier alles nach einem Design Pattern schreit. Da ich mich diesbezüglich aber nicht sehr gut auskenne bin ich über jeden ernst gemeinten Tipp sehr dankbar! 🙂

Beste Grüße
geneticZ
 
Zuletzt bearbeitet von einem Moderator:
Design Pattern sind kein Fingerschnippsen, welche automatisch Code x in Code y umwandeln,

was du brauchst ist ein Kopf zum Denken und bisschen Vorstellung vom Code,
denkbar ist z.B. eine Basisklasse mit leerem Konstruktor und eine init()-Methode für die diversen Parameter,
dann brauchen alle Subklassen zur Initialisierung gar nix schreiben,
es gibt aber das Risiko dass ein Objekt ohne Initialisierung verwendet wird, was mit Konstruktor weniger wahrscheinlich ist

eine andere Richtung wäre, die Parameter alle in einem Objekt zu sammeln und so die Konstruktor-Parameter auf einen einzelnen zu reduzieren,
nützlich wenn auch noch ganz andere Methoden-Hierarchien zu durchwandern sind,

das sind alles natürliche Ideen aus der Sache selbst, unabhängig davon, ob sich vor 12,4 Jahren irgendjemand in South Carolina einen Namen dafür ausgedacht und ein Buch dazu geschrieben hat..
 
Hallo Slater und danke für deine Antwort.
Ideen aus der Sache selbst habe ich genügend, Vorstellung vom Code ebenfalls (genau genommen bestehen bereits sehr viele Teile) und auf ein Sammelobjekt bin ich davor auch schon gekommen. Ich suche aber nach einer noch eleganteren Lösung. Unabhängig davon ob es dich interessiert dass vor 12,4 Jahren irgendjemand in South Carolina sich einen Lösungsweg für immer wiederkehrende Probleme ausgedacht und dem ganzen einen Namen gegeben hat, würde mich eben genau ein solches, falls vorhanden, mehr als erfreuen! 🙂
 
Zuletzt bearbeitet von einem Moderator:
Unabhängig davon ob es dich interessiert dass vor 12,4 Jahren irgendjemand in South Carolina sich einen Lösungsweg für immer wiederkehrende Probleme ausgedacht und dem ganzen einen Namen gegeben hat, würde mich eben genau ein solches, falls vorhanden, mehr als erfreuen!
Die Lösungen hat man sich nicht vor 12,4 Jahren ausgedacht, sondern nur die Namen, weil die Lösungen eben wiederkehrend waren bzw. sind.

D.h., das man zwangsläufig Design Patterns im Code hat, wenn der Code einigermaßen strukturiert ist, auch ohne jemals etwas von Design Patterns gehört zu haben.
Design Patterns keine exakten Rezepte bei deren Einhaltung immer etwas leckeres rauskommt.

Denke du solltest erstmal 2 Dinge trennen:
- Import der (konvertierten/transformierten) Daten
- das neue System

Schon solltest du erkennen, dass es wohl nicht so gut wäre wenn alle deine Klassen von XML Daten ausgehen, denn das sollte eigentlich passieren, bevor die App läuft.
Also brauchen deine Klassen eigentlich gar nix von XML zu wissen.
 

Zurück
Oben