OOP wirklich nicht möglich?

[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.

[DeddyH]

Man kann in einer Interface-Deklaration überhaupt nichts implementieren, das ist ja gerade deren Sinn. Wenn Du von außen auf ein Interface zugreifst, weißt Du zunächst einmal nur, dass die dahinterliegende Objektinstanz garantiert alle Eigenschaften besitzt und Methoden implementiert, die im Interface vereinbart sind.

[stahli]

@Delbor

Ich denke, Du musst Deinen Grundsatzüberlegungen nochmal etwas ordnen und strukturieren.

Nimm Dir mal ein Blatt Papier und zeichne Dir mal einen Plan, wo welche Zuständigkeiten geregelt werden sollen. Je klarer Dir das gelingt, je strukturierter wird Dein Programm aufgebaut sein.

Für Außenstehende ist vermutlich schwer nachzuvollziehen, was Du aktuell genau vorliegen hast und was Du ändern willst.

Z.B. ist m.E. bisher nicht klar geworden, wie diese Komponenten

Delphi-Quellcode:

    FTblBildText : TTblBildText; // FBildDescribeTabelle : TBildDescribeTabelle;
     FTblAlbum : TTbl_Album; // FKategoryTabelle : TKategoryTabelle;

aufgebaut sind. Haben sie noch eine Verbindung zur Datenbank oder nicht?
Wenn nicht, warum sind es dann unterschiedliche Klassen und warum sind die Felder unterschiedlich benannt?
Wenn ja, warum nimmst Du nicht eine Klasse, die die Daten unabhängig von einer Datenbank verwaltet und bearbeitet?

Wie viele Daten verwaltest Du insgesamt in der Anwendung? Können alle Daten insgesamt im Speicher gehalten werden oder ist die Datenbank so groß, dass immer nur bestimmte Datensätze daraus abgeholt werden können?

Das sind viele grundsätzliche Fragen, die eigentlich erst mal geklärt werden müssten und zu entsprechend unterschiedlichen Lösungen führen werden.

Wie in #12 schon mal angesprochen, musst Du Dir eine übersichtliche Struktur überlegen, die klare Zuständigkeiten und Verbindungen verschiedener Projektmodule abbildet.

Dafür gibt es dann je nach den Gegebenheiten verschiedene Lösungsmöglichkeiten.


Was ich generell nicht verstehe ist, dass Du Deine Businessklassenstruktur änderst, wenn Du die Datenbank wechselst oder die Tabellen in der Datenbank andere Namen haben.

Nach meiner Überlegung müsstest Du in Deinem Projekt das "Datenbankmodul" anpassen, aber nicht die Businessklassen.


Interfaces zu verwenden kann sinnvoll sein, muss es aber nicht in jedem Fall. Wenn Du damit noch keine Erfahrungen hast, würde ich die Projektstruktur erst mal überarbeiten und auf Interfaces verzichten. Da hängt noch einiges an notwendigen Anpassungen dran, die jetzt vielleicht unnötig verwirren würden.

Statt dessen solltest Du eine Datenbankunit oder Datenbankklasse einführen, die alle Zugriffe auf die alte Datenbank kapselt - so dass Deine Anwendung nicht mehr die Datenbank selbst kennt, sondern nur noch Deine Datenbankunit oder Datenbankklasse.
Dann kannst Du eine neue Datenbankunit oder -Klasse aufbauen, die die selben Schnittstellen nach außen hat, aber intern auf eine andere Datenbank geht.

So hättest Du schon mal eine gute Trennung der Zuständigkeiten.