OOP wirklich nicht möglich?

[Delbor]

Hi stahli

Zitat:

Da wäre zu sagen: Rechtsklick / Refactoring / Umbenennen.

In etwa so ist QueryCMResultClass entstanden, wobei ich in den meisten Fällen den Sync-Arbeitsmodus verwendet habe.
Die Frage zielte eigentlich hauptsächlich darauf ab, wie ich das nächste mal vorgehen muss, um die Sache möglichst einfach durchzuziehen.
Vor kurzem habe ich ein Interface-Testprogrämmchen begonnen.
Wenn ich die Sache richtig verstanden habe, müsste ich TQueryResultClass statt von TPersistent von TInterfacedobject, IMeinInterface abbleiten, letzteres inklusive der Member deklarieren und die Member in TQueryResultClass implementieren. Somit hätte ich, wenn ich das richtig verstehe, durchaus eine OOP-Lösung.

Gruss
Delbor

[stahli]

Irgendwie verstehen wir uns nicht so richtig...

Also mit OOP arbeitest Du ja schon, da Du mit Klassen und Objekten arbeitest.

Mit Interfaces zu arbeiten ist schon auch sinnvoll, bedingt aber einige Einarbeitungszeit und erhöht den Schreibaufwand, da man die Klassenmember immer zwei mal schreiben muss und Delphi dabei wenig unterstützt.
Mit der automatischen Referenzzählung hat man ggf. einen Vorteil, weil man sich nicht um die Lebenszeit der Objekte kümmern muss. Das braucht aber auch einige Zeit, bis man damit richtig umgehen kann und das verinnerlicht.

Was auf jeden Fall eine Hilfe ist, ist die Abstraktion, die man durch Interfaces erhält.

Aber genau gegen diese Abstraktion wehrst Du Dich schon bei Deinen Klassen, weil Du die völlig abhängig von Deinen Datenbanktabellen gestalten willst. Das ist wirklich nicht sinnvoll. Wenn Du jetzt mit Deinen Datenbankabhängigen Klassen noch Interfaces unterstützen willst, dann hast Du noch mehr Aufwand und noch weniger Nutzen.

Was ich oben schon versucht habe zu vermitteln ist, dass die Businessklassen ihren Kram so erledigen sollen, dass sie optimal und logisch arbeiten, ohne irgendeinen Bezug zur Datenbank zu haben.
Dann baust Du eine Datenbank, die Ihre Aufgabe, Daten zu verwalten, gut erledigt. Da eine relationale Datenbank keine Delphi-Klasse ist, wird es in der Datenschicht irgendwie anders aussehen, als in der Business-Schicht. Wurscht!!!!!!
Jetzt brauchst Du einen Vermittler, der Daten aus den Objekten in die Datenbank schreibt oder in der anderen Richtung in die Objekte lädt.

Wenn Du das versuchen würdest, hättest Du eine gute Projektstruktur mit einer (relativ) guten Entkopplung der einzelnen Schichten.


Wenn das getan ist - und wirklich erst dann! - könnte man die Entkopplung noch weiter treiben und Interfaces einführen.
Das wäre aber der I-Punkt auf eine saubere Trennung der einzelnen Schichten.


Also mein Tipp fürs nächste Mal:

1) Businessklassen für die Buisnesslogik (ohne Abhängigkeit und zwanghafte Namensgleichheit zur Datenbank).
2) Datenbank in sich sinnvoll aufbauen (ohne Abhängigkeit auf die Klassen)
3) Datenbankmanager zum Speichern und Laden von Daten.
4) GUI nur mit Bezug auf die Business-Schicht

[TigerLilly]

Nochmal. Decorator.

Mach eine Klasse, deren Properties so heißen, wie du möchtest, deren Getter+Setter aber auf deine Originale Klasse zugreifen.
Alle Methode dieser Klasse benennst du, wie du möchtest, die rufen aber nur Methoden deiner alten Klasse auf.

Wenn das nicht das ist, was du möchtest, weiß ich leider nicht weiter.

Vergiss das mit den Interfaces vorerst, das ist ein Implementierungsdetail + ich glaube, du weißt noch nicht, was du implementieren möchtest.

[Delbor]

Hi TigerLilly

Zitat:

Nochmal. Decorator.

Mach eine Klasse, deren Properties so heißen, wie du möchtest, deren Getter+Setter aber auf deine Originale Klasse zugreifen.
Alle Methode dieser Klasse benennst du, wie du möchtest, die rufen aber nur Methoden deiner alten Klasse auf.

Ups! Offenbar hab ich da was überlesen, bzw. einen fatalen Denkfehler gemacht, indem ich dachte, die Basisklasse würde da (auf der von mir verlinkten Seite zum Decorator Pattern) gewissermassen mit einem Interface 'dekoriert'.

Ich werde mir da doch noch einiges a Tutorials und Theorie einverleiben müssen.

Gruss
Delbor

[stahli]

Ich denke nicht, dass das Decorator-Pattern hier wirklich hilfreich ist.

Das Ziel ist ja, dass die Klassenmember so heißen, wie die Datenbankfelder.
Man müsste also die DB-Zugriffe in den Originalklassen auf die neue Datenbank anpassen und um die alten Klassen neue Klassen hüllen, die nach außen neue Namen für die alten Member anbieten.

Das wäre ja noch mehr Durcheinander als so schon.

Wenn Du von den namensgleichen Klassenmembern und Tabellenfeldern nicht abrücken willst und die Tabellenfelder neue Namen erhalten, dann ist der einfachste Weg, tatsächlich das Refactoring-Umbenennen.


Dass diese Namensgleichheit aber unnötig und nachteilig ist, habe ich ja schon öfter erwähnt. ;-)

[TigerLilly]

Zitat:

Das Ziel ist ja, dass die Klassenmember so heißen, wie die Datenbankfelder.

Ja eben. 4 unterschiedliche Datenbanken --> 4 unterschiediche Datenbankfelder --> 4 Dekorators. Voila.

[TiGü]

Ich verstehe nicht, warum du trotz meines Beitrages vor einigen Tagen immer noch nicht die Gemeinsamkeiten der jeweiligen Klassen in eine Basisklasse ziehst.

[Stevie]

Zitat:

Zitat von TigerLilly (Beitrag 1383730)

Nochmal. Decorator.

Mach eine Klasse, deren Properties so heißen, wie du möchtest, deren Getter+Setter aber auf deine Originale Klasse zugreifen.
Alle Methode dieser Klasse benennst du, wie du möchtest, die rufen aber nur Methoden deiner alten Klasse auf.

Das nennt sich Adapter und nicht Decorator.

[TigerLilly]

:oops: Da hast du recht.

[Delbor]

Hi zusammen

@TiGü

Zitat:

Ich verstehe nicht, warum du trotz meines Beitrages vor einigen Tagen immer noch nicht die Gemeinsamkeiten der jeweiligen Klassen in eine Basisklasse ziehst.

Stimmt eigentlich... So, wie ich das jetzt rückwirkend sehe, war ich zu sehr beschäftigt, nach anderen Lösungsmöglichkeiten zu suchen.
Um mich selbst aus Beitrag 11 zu zitieren:

Zitat:

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.

Eine solche "TQueryresult-Klasse" aber kann gar keine Felder analog der Abgefragten Datenbank haben, und zwar schlicht und einfach, weil diese Felder zur Entwurfszeit einer solchen Klasse nicht bekannt sind.
An diesen Umstand hatte ich nicht mehr gedacht, als DeddyH und Stahli meinten, die Klassenmember dürften nicht so heissen wie die Tabellen-/ Feldnamen der DB.
Um TigerrLilly zu zitieren:

Zitat:

Ja eben. 4 unterschiedliche Datenbanken --> 4 unterschiediche Datenbankfelder --> 4 Dekorators. Voila.

Zum Decorator Pattern hab ich da noch eine Umsetzung mit Delphi gefunden. Die von mir zuerst verlinkte Seite enthält C++ - Codeschnipsel. Und da ich nie mit C++ gearbitet habe, kann das zu Verständnisproblemen führen.

Gruss
Delbor