Speichern einer allgemeinen Liste (Inhalt sind beliebige Objekte)

[Astobix]

Hallo,

im Rahmen einer Schulaufgabe (das ist keine Hausaufgaben-Frage, keine Angst ), soll ich Funktionen zum Abspeichern und Laden einer Liste schreiben, die die anderen Schüler dann zum Programmieren eines kleinen Vokabel-Trainers benutzen werden.
Gegeben ist mir dafür eine u_list Unit, die die Programmierung einer Liste enthält, in der beliebige Daten gespeichert werden können (es werden TObjects gespeichert).

Theoretisch soll ich nun Methoden schreiben, mit denen ich Vokabeln abspeichern (und Laden) kann. Das ist auch erstmal nicht das wirkliche Problem. Ich fände es allerdings extrem unschön, in einer "allgemeinen" Liste (beliebige Daten können gespeichert werden) Methoden zu schreiben, die exakt einen Typ von Daten speichern/laden können, da damit irgendwie die Vielseitigkeit der Listenklasse abhanden kommt.
Somit komme ich zu meiner ersten Frage:
Kann man Methoden schreiben, die allgemeine Daten abspeichern können (ein TObject), und diese exakt gleich wieder einlesen?


Da ich keine Möglichkeiten kenne, Daten allgemein abzuspeichern, habe ich mir gedacht, ich erstelle einfach eine Klasse TStringList, die von der Liste erbt.
An den Stellen, wo vorher die Klasse TObject vorkam, habe ich das ganze umgeschrieben und Strings verwendet. Um möglichst wenig Code zu wiederholen, habe ich die jeweiligen Funktionen und Prozeduren als overload makiert und in etwa so programmiert:

Delphi-Quellcode:

procedure TStringList.insertBefore(data: String);
var stringElement : TStringElement;
begin
 stringElement := TStringElement.create();
 stringElement.data := data;

 insertBefore(stringElement); //Das ist die Zeile, weswegen ich overload benutzen wollte.
end;

Die Klasse TStringElement beinhalted dabei nur einen String.

Das Problem was ich nun habe, wenn ich overload benutze, ist, dass ich auch bei einer StringList immernoch auf die inserBefore(TObject) Prozedur zugreifen kann.
Bevor die anderen Schüler dadurch aber ungewollte Fehler verursachen, möchte ich ihnen gerne diese Möglichkeit garnicht geben.
Daher meine zweite Frage:
Kann man - ohne die eigentliche Listenklasse zu verändern - die Prozeduren der Listenklasse innerhalb der Stringklasse verfügbar machen, außerhalb allerdings nicht?

Ich hoffe ihr versteht meine Fragen und bedanke mich bereits jetzt für die Zeit, die ihr zum helfen investiert!

Vielleicht noch als kleine Übersicht, was das Ziel ist:

• Ich habe eine Klasse Liste gegeben, die allgemeine Objekte speichert
• Ich möchte nur Strings speichern, aber damit nicht die eigentliche Listenklasse behindern
• Die Schüler sollten nach Möglichkeit nur mit den Befehlen der Liste zu tun haben, keine weiteren (außer speichern und laden)
• Die Klasse soll für andere Nutzer möglichst Narrensicher sein

Im Anhang habe ich euch mal die beiden Units U_StringList und U_List gestellt, falls sich jemand dort Überblick verschaffen will.

[jaenicke]

Ich würde den Schülern schlicht die Zusatzaufgabe geben ein LoadFromStream bzw. SaveToStream zu implementieren. Sprich z.B. von einem Basisobjekt abzuleiten, in dem diese Methoden abstrakt deklariert sind.

Allgemein ein TObject speichern nennt sich Marshalling, aber bei Delphi 6 dürfte das schwierig werden. Von TComponent abgeleitete Objekte lassen sich auch dort schon mit ReadComponent und WriteComponent speichern und laden, allerdings nur published Eigenschaften. Für ein Marshalling von Objektinhalten, die nicht published sind, reicht die RTTI von Delphi 6 soweit ich weiß nicht aus.

[Sir Rufo]

Eine weitere Möglichkeit besteht darin alle zu speichernden Klassen von TPersistent abzuleiten.

Per TPersistent.Assign bzw. indirekt per TPersistent.AssignTo können dann die Daten-Instanzen an eine Speicher-Instanz übergeben, bzw. daraus wiederhergestellt werden.

Wenn man völlig frei von allem sein möchte, dann gibt man ein Interface vor, was alle zu implementieren haben.

[BUG]

Ein anderer Anstoß: Warum muss deine Listenklasse von der allgemeinen Liste erben, wenn sie gar nicht so benutzbar sein soll? Das deutet eher darauf hin, das du die allgemeine Liste ein Attribut deiner Listenklasse ist.

Vererbung ist ein wichtiges Konzept, aber nicht die Antwort auf alles

[Astobix]

Vielen Dank für die Antworten!

Zitat von BUG:

Ein anderer Anstoß: Warum muss deine Listenklasse von der allgemeinen Liste erben, wenn sie gar nicht so benutzbar sein soll? Das deutet eher darauf hin, das du die allgemeine Liste ein Attribut deiner Listenklasse ist.

Vererbung ist ein wichtiges Konzept, aber nicht die Antwort auf alles

Die Idee hatte ich in der Tat auch, habe sie aber dann erstmal wieder vergessen, weil ich es gerne durch Vererbung lösen wollte. Da dies scheinbar aber nicht so einfach geht, ist es vermutlich wirklich sinnvoller, die gennante Methode von dir zu nehmen

Ich versuch das erstmal dann so, es sollte eigentlich klappen; falls nicht, melde ich mich nochmal