Klassen zur Laufzeit dynamisch erweitern

[Captnemo]

Hi,

sagen wir ich habe eine Klasse:

Delphi-Quellcode:

TTestklasse = Class(TObject)
  Hesteller: String;
  Modell: String;
  Breite: integer;
  Hoehe: integer;
end;

und ich möchte diese Klasse zur Laufzeit um eine variable Anzahl an Eigenschaften erweitern, die aber vom User definiert werden können sollen. Würde das irgendwie gehen, oder ist das nicht möglich?

[Uwe Raabe]

So, wie du es formulierst, geht es nicht. Die Eigenschaften einer Klasse müssen dem Compiler bekannt sein. Du kannst aber z.B. eine TStringList in die Klasse mit aufnehmen und die User-Daten in dxeren Name-Value-Pairs speichern. Es gibt aber sicher noch andere Herangehensweisen.

[himitsu]

Natürlich kann man per Hand die RTTI umschreiben, Speicheranweisungen anpassen uvm., aber sowas macht man nicht.
(ich weiß, gemanagete Programmiersprachen ala JavaScript, PHP oder eventuell C# können sowas)

Delphi-Quellcode:

property Werte[Name: string]: Variant read ... write ...;

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1187262)

Natürlich kann man per Hand die RTTI umschreiben, Speicheranweisungen anpassen uvm., aber sowas macht man nicht.

Macht m.E. auch keinen Sinn. Da die Eigenschaften beim Compilieren nicht bekannt sind, können sie im Source-Code auch nicht vorkommen.

Man sollte erstmal klären, was mit diesen Eigenschaften und ihren Werten eigentlich alles passieren soll (Eingeben, Speichern, Laden, Ausgeben). So ist das Thema etwas sehr schwammig.

[himitsu]

Kommt drauf an.
Wenn die Objekte per RTTI angesprochen werden, dann könnte man das schon verwenden.

z.B. der TReader/TWriter der VCL geht ja nur via die RTTI auf Property los, welche in der DFM gespeichert sind.

[Captnemo]

Nein, sowas über RTTI will ich nicht machen.

Die an eine TSTringList war mir auch schon gekommen, und ich werde es auch so machen. Ich wollte nur mal fragen, ob es möglicherweise doch eine Möglichkeit gibt, von der ich nix weiß.

Dank für eure Antworten.

[DanielJ]

Hallo,

die Frage was du damit machen willst ist durchaus berechtigt. Eventuell könnte auch eine Objektliste und eine Reihe von "Eigenschaften-Objekten" dich weiter bringen. Wenn die einzelnen Eigenschaften mehr können sollen als eine Stringrepräsentation ihres Wertes zu speichern ...

LG,
Daniel

[Stevie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1187263)

Zitat:

Zitat von himitsu (Beitrag 1187262)

Natürlich kann man per Hand die RTTI umschreiben, Speicheranweisungen anpassen uvm., aber sowas macht man nicht.

Macht m.E. auch keinen Sinn. Da die Eigenschaften beim Compilieren nicht bekannt sind, können sie im Source-Code auch nicht vorkommen.

Man sollte erstmal klären, was mit diesen Eigenschaften und ihren Werten eigentlich alles passieren soll (Eingeben, Speichern, Laden, Ausgeben). So ist das Thema etwas sehr schwammig.

In .Net (genauer gesagt WPF) gibt es die sogenannten Dependency Properties. Sowas kann durchaus Sinn machen, auch wenn man nicht direkt im Sourcecode darauf zugreifen kann (im direkten Sinn von

Delphi-Quellcode:

myObject.MyProperty

meine ich).

Mit meiner abgespeckten Delphi Implementierung davon kann man durchaus Klassen mit Eigenschaften erweitern (intern über RTTI Erweiterungen).

[Sir Rufo]

Es gibt aber auch noch Custom Variant Type (Beispiel TDataSet)

[Furtbichler]

Nur mal so: Jedes TDataset implementiert dieses Verhalten (zur Laufzeit dynamisch erweiterbare Eigenschaften).

[Uwe Raabe]

Zitat:

Zitat von Furtbichler (Beitrag 1187409)

Nur mal so: Jedes TDataset implementiert dieses Verhalten (zur Laufzeit dynamisch erweiterbare Eigenschaften).

Da war doch mal was...
A Magical Gathering – Part 1
A Magical Gathering – Part 2

[himitsu]

In PHP5 kann man z.B. Property im Code verwenden, welche es garnicht gibt. (das wird dann über die Methoden _get und _set behandelt)

In Delphi kann man soein Verhalten auch verwenden, wenn man seine Objekte in einem OleVariant verpackt, aber leider gibt es dort dann keine Autovervolständigung im Codeeditor.

[Uwe Raabe]

Ich glaube, wir kommen von dem eigentlichen Thema etwas ab. Wenn ich das richtig sehe, ist es der Endanwender, der diese zusätzlichen Eigenschaften definiert. Demnach kann der Entwickler diese nicht kennen und sie können im Source-Code gar nicht vorkommen - es sei denn, man vereinbart schon mal die Namen (aber dann könnte man sie auch gleich implementieren). Daher braucht man auch kein Verfahren, wie der Compiler mit ihnen umgehen kann.