OOP wirklich nicht möglich?

[Delbor]

Hi zusammen
@Elrond

Zitat:

Ich muss zugeben das ich das Problem überhaupt nicht verstehe, was genau möchtest du?

TQueryresultClass ist die Elternklasse; sie bildet die Haupttabelle "BildTabelle" (oder neu und kürzer tbl_bild) ab. Diese in der DB vorhandene "BildTabelle" verfügt über die DB-Felder "BildId", "Thumbnail", "Bitmap" und enthielt ursprünglich auch mal ein Feld "NEF" für die Rohbilddaten. Entsprechend enthält TQueryresultClass private Felder, die diesen Tabellenfeld-Namen entsprechen.
Weiter enthält TQueryresultClass Felder weiterer Unterklassen, welche wiederum uber Felder verfügen, die die von ihnen beschriebenen Detailtabelle repräsentieren.
Das ist im Grunde nichts weiter als eine in klassenform organisierte Menge an Variablen bestimmten Typs( Integer, Strind, Blob.

Nun stelle ich mein Programm von MySQL auf SQLite um; gleichzeitig aber habe ich der Datenbank kürzere, aber trotzdem beschreibende Tabellen- und Feldnamen verpasst. Das heisst nichts anderes, als dass ich jetzt eine Klasse bauen darf, die dasselbe wie TQueryresultClass tut, deren Felder, Propertys und Methoden aber anders heissen. So ist zum Beispiel der Name "BilddescribeTabelle" durch "TblBildText" ersetzt worden.
Da TQueryresultClass gerade mal 2 Vorfahren hat (TObject und TPersistent), kann ich nicht einfach eine neue Klasse ableiten und da neue Felder, Propertys und Methoden einführen, sondern muss einen in den Funktionen soweit identischen Nachbau erstellen.

@TiGü
Ja, das wäre eine Möglichkeit, bzw. das ist der normale Weg der Vererbung. Warum nur hatte ich beim ersten Blick das Gefühl, ich würde es genau umgekehrt machen? Offenbar aber lag genau da mein gordischer Knoten.
Bei nochmaligem durchlesen wird klar: TCustomQuery enthält die Felder(...), die sich in beiden Nachkommen nicht ändern. Die andern werden in den betreffenden Nachkommen neu eingeführt.
Apropos Gordischer Knoten: Ein Hintergedanke war auch, eine Vorfahrklasse zu erstellen, die letztlich an solche "TQueryresult-Klassen" beliebiger Struktur vererben kann, so dass darin Daten aus Tabellen beliebigen Aufbaus gespeichert werden könnten, wie zB. aus einer Adressdatenbank oder sonstwas.

Gruss
Delbor

[stahli]

Mir geht es wie Elrond.

Ich würde die Logik eher in verschiedene Ebenen aufteilen.

Deine Buinessklassen sollten die Daten so verwalten und die Felder so benennen, wie es für die Geschäftslogik Sinn macht.

Dann müsstest Du Deinen Klassen die Fähigkeit geben, sich in eine Datenbank zu speichern und die eignen Daten daraus wieder zu laden.
Da spielt dann für die Businessklassen keine Rolle, was da für eine Datenbank genutzt wird.

Welche Datenbank genutzt wird und wie die Statements dazu aussehen, könnte in austauschbaren Units oder Komponenten geregelt werden.
Dann kannst Du zunächst MyUnit_MySql verwenden und dort alle bisherigen Funktionen deklarieren und dann diese durch MyUnit_SQLite ersetzen.
Der Interface-Abschnitt müsste die selben Methoden veröffentlichen aber im Implementations-Abschnitt wären diese jeweils für eine andere Datenbank umgesetzt.

Falls Du Dich mit Interfaces auskennst oder Dich damit befassen willst, wären diese eigentlich prädestiniert für solche Anwendungsfälle.

In jedem Fall ist es sinnvoll, die Zuständigkeiten wie Geschäftslogik zum einen und Datenbankverbindung zum anderen möglichst entkoppelt voneinander zu regeln. Für eine detaillierte Umsetzung gibt es dann wieder mehrere Möglichkeiten.

[Elrond]

Zitat von Delbor:

Nun stelle ich mein Programm von MySQL auf SQLite um; gleichzeitig aber habe ich der Datenbank kürzere, aber trotzdem beschreibende Tabellen- und Feldnamen verpasst. Das heisst nichts anderes, als dass ich jetzt eine Klasse bauen darf, die dasselbe wie TQueryresultClass tut, deren Felder, Propertys und Methoden aber anders heissen. So ist zum Beispiel der Name "BilddescribeTabelle" durch "TblBildText" ersetzt worden.

Wenn dies dein Hauptproblem darstellt, dann wäre die Verwendung eines DB Wrappers die sauberste Lösung. Dieser Wrapper generiert dir automatisch aus deiner Datenbank die passenden Delphiklassen. Dieser Ansatz ist etwas ungewöhnlich im vergleich zum klassischen Object-Relational Mapping ala Hibbernate, funktioniert jedoch genauso gut. Somit müsstest du nur deinen Wrapper beim wechseln der Datenbank anpassen.

[Delbor]

Hi Elrond

Meinst du sowas?

Gruss
Delbor

[TigerLilly]

Das sieht so aus, als ob du für einen Fehler, den du gemacht hast (oder etwas, das du jetzt einfach besser weißt), einen eleganten Workaround suchst. Mir kommt diese Lösung sehr kompliziert und schwerfällig vor.

Kannst du nicht alles kübeln + neu beginnen? Und diesmal von Beginn an besser?

Oder wenigstens mit suchen/ersetzen alles auf den gleichen Stand bringen, den du gerne hättest?

[Delbor]

Hi Tigerlilly

Zitat:

Das sieht so aus, als ob du für einen Fehler, den du gemacht hast (oder etwas, das du jetzt einfach besser weißt), einen eleganten Workaround suchst. Mir kommt diese Lösung sehr kompliziert und schwerfällig vor.

Das ist nicht ganz falsch. Zu Anfang erstellte ich mir in MySQL-Workbench ein Datenbankmodell. Dabei ergaben sich, zB. in einer n:m-Zwischentabelle, so unsägliche Namen wie "BildDescribeTabelle_Bildtabelle_idBild" für ein Fremdschlüsselfeld. Auch wenn ich das relativ früh bemerkte, wollte mir vorerst keine gangbare Lösung einfallen - etwa Text statt Describe oder tbl statt Tabelle für einen immer wieder auftauchenden Teilstring.

Schwerfällig ist eigentlich der Part, der sich, ob unschön oder nicht, zuallererst anbietet: Ich schreibe eine neue Klasse, die genau das tut, was die alte macht, aber mit Feldern und Methodenköpfen analog der SQLite-Datenbank. Nicht unmöglich, aber eine Sisiphusarbeit - einmal ein klein wenig nicht aufgepasst, und schon beginnt später die Suche nach der Nadel im Heuhaufen.
Wobei das nicht mal das Hauptproblem ist. Es wäre aber wünschenswert, eine Customklasse zu haben, um, sollte ich in Zukunft vor dem selben Problem stehen, dieses mit OOP lösen zu können.

Zitat:

Kannst du nicht alles kübeln + neu beginnen? Und diesmal von Beginn an besser?

Eher nicht. Zum einen würde dies bedeuten, ein funktionierendes Programm neu zu bauen anzufangen und zum andern wäre die Sache mit der Klasse TQueryresultClass nicht gelöst - es sei denn, du meinst mit 'kübeln' gerade mal TQueryresultClass. Das hiesse dann: da weitermachen, wo ich jetzt stehe, nämlich beim Neuerstellen von TQueryresultClass unter Verwendung der nun aktuellen Namen.

Aber vielleicht ist das noch viel einfacher, als ich mir gedacht habe: TQueryresultClass erhält ein Feld "Params" und feuert einen Event - das Datenmodul, oder wer auch immer, erhält einen Eventhandler, der die Tabellen und Felder der DB abfragt. Soweit, so gut: wie TQueryresultClass in die Strings der Params-Liste die Ergebnisse des Querys speichert, weiss ich erstmal noch nicht könnte so geschehen.

Andrerseits ist das bis jetzt auch nur die Halbe Wahrheit - TQueryresultClass besitzt Unterklassen, die auch umbenannt werden müssten...

Obigen Absatz habe ich mal stehen lassen. Durchgestrichen habe ich ihn wegen der Unterklassen, die auf diese Weise nicht deklariert werden können, Zumindest so, wie ich das bis anhin sehe.

Im Anhang lege ich mal die TQueryresultClass-Unit bei, um den Aufbau der Klasse zu verdeutlichen.

Gruss
Delbor

[Elrond]

Zitat von Delbor:

Hi Elrond

Meinst du sowas?

Gruss
Delbor

Nein das ist einfach nur ein Wrapper um eine DB DLL.
Ich meine einen Wrapper der dir aus deinen Datenbankmodell die passenden Delphiklassen generiert, z.B. wird aus Tabelle A mit Spalten AA und AB eine Klasse A mit den properties AA und AB.
Natürlich kümmert sich der Wrapper auch darum deine Objekte zu persistieren und wieder aus der Datenbank zuladen. Der entscheidende Unterschied zu den gängigen OR Mappern besteht darin das du zuerst deine Datenbank beschreibst und nicht deine Klassen.

[mkinzler]

Das unterstützen die gängigen OR-Mapper eigentlich auch.

[Delbor]

Hi zusammen

Inzwischen habe ich, wie vor einiger Zeit von TigerLilly angesprochen, quasi "von Hand", bzw. durch Suchen und ersetzen, eine neue Klasse analog TQueryresultClass erstellt. Soweit wär eigentlicheine Vorausetzung für den Umbau gegeben.
Trotzdem hat mich die Sache nicht losgelassen, und so hab ich auch das gefunden. Weiter habe ich mir auch die verschiedenen Beiträge und Tutorials zu Interfaces hier und auf andern Webseiten, insbesondere Stahlisoft und Youtube, angesehen.
Die OOP-Vorgehensweise nach dem Decorator Pattern wäre demnach also gewesen:

1. Ein Interface zu deklarieren(TInterfacedobjekt und (muss ich nochmal nachsehen)
2. TQueryresultClass nicht nur von TPersistent, sondern zusätzlich von meinem Interface abzuleiten

Noch nicht ganz klar ist, ob ich die Methoden, die meine neu benannten Tabellen auslesen, im Interface nur deklariere oder auch implementiere ( Die Embarcadero Onlinehelp irritiert mich da etwas).
So aus dem Stegreif heraus: Ja zu letzterem und anschliessend in TQueryresultClass nur deklarieren, damit ich sie von da auch ausrufen kann. Diese Frage wird mir letztlich endgültig klar, wenn ich mir ein Testprogrämmchen geschrieben habe.

Gruss
Delbor

[TigerLilly]

Fein, dass mein Vorschlag des Decorator Patterns wieder auftaucht. *eiteldreinschau*

Aber der decorator macht ja eigentlich was anderes, als du hier beschrieben hast:Ein decorator legt eine andere Benutzerschicht über deine Klasse und reicht so Funktionalitäten durch. So kannst du die Methoden des Decorators aufrufen und der routet das weiter an die alte Klasse. das ist eine recht elegante Methode, wenn man wie du ja auch - Klassen umbaut und beide Varianten aktiv halten möchte.

Interfaces sind cool, haben mit dem Entwurfsmuster aber nichts zu tun. Interfaces sind operativ (=wie mache ich es), Entwurfsmuster sind taktisch(=was mache ich?). Und eine Strategie (=warum mache ich das?) braucht es natürlich auch.