Hallo zusammen!
Ich habe ein Interface gebaut, um ein Datenobjekt abzubilden. In diesem Interface habe ich das Attribut "countries" definiert.
Das habe ich so gemacht, um das Interface in einer Klasse zu implementieren, die die richtigen Daten ermittelt und speichert (Datenbank) und eine Klasse mit Testdaten zu haben.
Beispiel
dbclass->read: select land1 from dbtab into table countries where id = ...
Testclass->read: countries = value #( ( 'DE' ) ( 'FR' ) ( 'IT' ) ).
Jetzt habe ich allerdings das Problem, dass ich Methoden benötige, um die Daten zu manipulieren und zu prüfen. Mit meinem Konstrukt müsste ich diese Methoden nun in jeder Klasse implementieren, was ich nicht möchte.
Mit add_Country möchte ich natürlich ein Land in die interne Tabelle einfügen.
Gleichzeitig möchte ich aber auch prüfen, ob es das Land überhaupt gibt und sicherstellen, dass das Land nicht doppelt vorhanden ist.
Beide Methoden möchte ich natürlich gleichermaßen auf die Testklasse als auch auf die DB-Klasse anwenden.
Ich benötige also ein Zugriffsobjekt zu meinem Datenobjekt.
Wie mache ich das am besten? Das Design Pattern Data-Access-Object trifft es mMn nicht.
Moin Enno,
lass deine Implementierungen von einer (abstrakten) Basisklasse erben, welche deine allgemeinen, wiederverwendbaren Methoden enthält. Ob du dann das Interface schon in die Basisklasse packst oder lieber in die instanziierbaren Klassen bleibt dir überlassen.
Naja, aber das Problem "Suche in lokaler Tabelle" vs. "Suche in Datenbank" wird man damit aber nicht los. Sprich du wirst trotzdem einige Methoden "doppelt" implementieren müssen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
Das ist richtig. Aber die Methoden unterscheiden sich auch deutlich. Die Prüfung, ob ein Land bereits in der Tabelle vorhanden ist oder nicht, sollte immer gleich sein.
Die Prüfung, ob ein Land bereits in der Tabelle vorhanden ist oder nicht, sollte immer gleich sein.
READ TABLE vs. SELECT 🤨
Oder hältst du die Daten für beide Implementierungen in einer internen Tabelle vor?
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ja, genau. ich lese erst alle zum Objekt zugehörigen Daten und diese werden dann verändert. das heißt, dem Objekt mit irgendeiner Id sind 3 Länder zugeordnet und in der Anwender kann Zuordnungen zu Ländern ändern. Dieses "Ändern" möchte ich auf jeden Fall testbar halten.