Objektorientiert Designfrage ?



  • Hallo,
    bin gerade dabei mich näher mit C++ und der objektorientierten Sprache auseinanderzusetzen.
    Bei der praktischen Umsetzung hapert es jetzt. Irgendwie bin ich mir nicht im klaren wie ich manche Sachen praktisch am idealsten Umsetze.
    Beispiel:
    Ich habe eine Klasse "Orte". Diese Klasse hat verschiedene Membervariablen für die ich Setter und Getter Methoden habe. Soweit kein Problem.
    Dann habe ich eine Klasse "Strassen". Da genau das selbe(Setter/Getter) mit zusätzlich einem Zeiger auf ein Objekt Ort.

    Diese Daten sollen aber später alle aus einer Datenbank geladen werden.
    Hier entsteht jetzt für mich das eigentliche Problem.
    1. In der Datenbank habe ich ja z.B. einen Primärschlüssel für die Orte. Sollte ich mir den dann auch in der Klasse "merken" ? Ich benötige den ja sonst eigentlic nur beim Löschen bzw. beim Updaten der Datensätze. 😕

    2. Wo gehört der Zugriff auf die Daten in der Datenbank hin um die jeweilige Instanz zu "füllen" ?
    Also z.B. dann für die Klasse "Orte" dann eine Methode, die mir das aus der Datenbank holt, bzw. ändert,löscht ?
    Oder mehr eine extra Klasse, die Strassen und Orte verwaltet und sich um das füllen bzw. ändern/löschen in der DB kümmert ? 😕

    Da komme ich ehrlich gesagt jetzt noch ins Schleudern. 😞

    Grüße
    Sandro



  • 1. Das nennt man Stil-Bruch... oder http://de.wikipedia.org/wiki/Object-relational_impedance_mismatch. Da muß man halt umdenken und sich eine Lösung ausdenken. Da gibt es keinen Königsweg, höchstens gängige Praxis. Und du mußt halt natürlich ein paar Daten in deinen Objekten halten, die für die RSDBMS unumgänglich sind.

    2. Das ist eine Designentscheidung. Du könntest sagen, Objekte sind selbst dafür verantwortlich. Nachteil ist, das du eine starke Kopplung zwischen Datenobjekt und DB-Zugriff hast. Vorteil ist, das es sehr einfach zu benutzen ist. Man kann aber die Kopplung entfernen und die Arbeiten aufteilen. Bedeutet etwas mehr Aufwand beim Benutzen, aber dafür ist die Wartung einfacher. Dort wo Licht, dort auch Schatten.


Log in to reply