Wie verwendet man "Unterklassen" am besten?

[p80286]

Hallo zusammen,

ich habe bisher eine mit einer Tlist einige Dateiinformationen verwaltet

Delphi-Quellcode:

type 
  tFileRec=record
             name   : string;
             ext    : string;
             path   : string;
             size   : cardinal;
             lastrd : tdatetime;
             lastwr : tdatetime;
           end;
  pFileRec = ^tFilerec;

Um mir das ewige Typecasting zu erparen hab ich daraus eine Klasse(TMyFiles) gemacht, wobei
.Add und .Items[i] jeweils tFileRec erwartet bzw. liefert, aber FileList[i] gibt einen Pointer zurück.

Wenn ich bisher z.B. mit allen .PAS Dateien etwas machen wollte ging das so ganz gut:

Delphi-Quellcode:

pasFileList:=TList.Create;
if tFileRec(allFileList[i]^).ext='PAS' then
     pasFileList.add(allFileList[i])
....
 { machwas }
  tFileRec(pasFileList[i]^).Name.....
 { machwas Ende} 
 pasFileList.Free;
    {

Danach waren noch alle (Datei)Daten in der allFileList vorhanden, und ich konnte ohne erneutes Einlesen z.B. alle XLS-Dateien verarbeiten.

Kann ich das auch mit TMyFiles erreichen ohne die Krücke Typecasting und Tlist zu nutzen?
Bräuchte ich ggf. zwei Free-Methoden?
eine um die Nutzdaten (records) frei zu geben und eine um die Pointer in den Orcus zu schicken?

Könntet Ihr mir hier auf die Sprünge helfen?

[xZise]

Wird ein Record nicht automatisch freigegeben? Natürlich nicht, wenn du einen Pointer da was mit New zugewiesen hast.

Und ich verstehe dein aktuelles Problem nicht so ganz: Du hast ein TMyFiles was intern eine TList speichert, und du greifst munter mit add und so drauf zu? Dann kannst du doch alles so lassen oder nicht?

MfG
Fabian

[shmia]

Aus dem Record eine Klasse machen und statt einem Array oder TList die Klasse TObjectList verwenden.

Delphi-Quellcode:

tFileObj=class(TPersistent)
public
  name : string;
  ext : string;
  path : string;
  size : cardinal;
  lastrd : tdatetime;
  lastwr : tdatetime;
  function Filename:string;      // liefert name + ext
  function FullFilename:string;  // liefert path + Filename
  procedure LoadFromSearchRec(const sr:TSearchRec); // kopiert Werte aus sr auf name,exe,size,...
  procedure Assign(Source: TPersistent);override;  // sollte man implementieren
end;

Leider gibt es viele Delphi-Programierer die den Schritt vom Record zur Klasse nicht vollziehen.
Ich vermute, dass es unter anderem daran liegt, dass man Objekt explizit freigeben muss.
Wobei hier aber TObjectList zur Hilfe kommt und die Sache angenehmer macht.

[p80286]

Das mit der TObjectlist muß ich mir mal anschauen.

Trotzdem hab ich da immer noch ein Verständnisproblem.
Ich habe eine Klasse die Verwaltungsdaten und die eigentlichen Daten enthält,
und eine zweite Klasse, die nur die Verwaltungsdaten enthält (enthalten soll). So etwas ähnliches wie ein View oder ein Filter. Nach aussen hin sollen sich beide gleich verhalten, wobei die zweite Klasse die erste zwangsläufig vorraussetzt. wenn ich die zweite Klasse "in den Orcus jage" muß die erste allerdings vollständig erhalten bleiben.
Tut mir leid, das ich es nicht besser beschreiben kann . Mir fehlt das richtige Vokabular.

Gruß
K-H

PPs
Ich schlepp noch ein paar Felder mehr mit mir herum, und da stecken noch einige Methoden in der Klasse.

P.S.

Zitat von shmia:

Ich vermute, dass es unter anderem daran liegt, dass man Objekt explizit freigeben muss.

sobald ich New(pMyRec) verwende, muß ich im Gegenzug Dispose verwenden, das ist nicht das Problem. Für mich ist es eher, warum ein TObject verwenden wenn ein Record bzw. eine Pointer/Record Kombination alles bietet was ich brauche. Glaub ich jedenfalls.

[Sir Rufo]

Du willst doch das TypeCast loswerden ... oder irre ich mich da?

[p80286]

Zitat von Sir Rufo:

Du willst doch das TypeCast loswerden ... oder irre ich mich da?

Äh, ja! warum?

K-H

[Hansa]

Du bist mit der TList vermutlich wirklich etwas zu kurz gesprungen. Wie gesagt : TobjectList und OwnsObjects sollte auf true stehen.

@Daniel : wäre gut, wenn man beim Schreiben sehen könnte, welche Delphi-Version eingesetzt wird.

So, der ganze Krempel, den man in die TObjectList packt, wird dann beim free der Liste auch komplettt weggeräumt. Das ist minimaler Aufwand. Du kannst ja sogar auch die Records komplett in die ObjectList packen. Die schluckt fast alles.

Hier mal noch, wie das ganze ungefähr aussieht :

Delphi-Quellcode:

TArtGrundDaten = record
  ID,
  nr : Integer;
  bez : string;  
// stark verkürzt !!
end;

TDatenObjekt = class(TObject)
  GrundDaten : TArtGrundDaten;
end;

DatenObjektListe : TObjectList;  // nimmt spezif. Daten von TDatenObjekt auf

for i := 0 to DatenObjektListe.Count - 1 do
  ArtAusgObjekt := TArtAusgObjekt (AusgObjektListe.Items[i]);

Ist das Letzte ein Typecast ? Die Nomenklatur ist da etwas ungenau. Nenne man das Konstukt, wie man will. Mir ists egal, weil es einwandfrei funktioniert ohne Nachteile.

Am Beispiel sieht man jedenfalls, wie man starre Records und Klassen kombinieren kann. Die Klassen, die den Record enthalten, werden an anderen Stellen jedenfalls noch OOP-mässig erweitert.

[xZise]

Moin,

Zitat von Hansa:

Du bist mit der TList vermutlich wirklich etwas zu kurz gesprungen. Wie gesagt : TobjectList und OwnsObjects sollte auf true stehen.[...]

Aber nur dann auf true stelle, wenn danach die Elemente nicht mehr bestehen sollen. Und das ist doch bei ihm nicht der Fall: Also OwnObjects auf false, dann werden die Objekte nicht automatisch freigegeben. Ansonsten werden sie beim entfernen aus der Liste (z.B. mit Delete oder Clear) freigegeben. Also auch, wenn du die Liste freigibst. Du kannst OwnObjects jederzeit via property setzen und beim TObjectList.Create. Standardmäßig steht OwnObjects auf true.

Zitat von Hansa:

@Daniel : wäre gut, wenn man beim Schreiben sehen könnte, welche Delphi-Version eingesetzt wird. [...]

So ich habe mal ein Eintrag erstellt.

Übrigens wenn ich das richtig verstehe würde ich das so in der Art machen:

Delphi-Quellcode:

TMetaData = class(TObject)
  Name : string;
  [...]
end;

TFile = class(TObject)
  MetaData : TMetaData;
  Data : TStream; // Oder TMemoryStream
end;

Alternativ könnte man auch TFile von TMetaData erben lassen. Dürfte glaub ich besser sein.

MfG
Fabian

PS: Ich würde das letzte als Typecast ansehen. Weil was ist, wenn du irgendwas anderes reinkloppst. Deshalb würde ich entweder Generics verwenden (gibts leider nicht für D7) oder halt das Kapseln.

[Chemiker]

Hallo,

Zitat:

Leider gibt es viele Delphi-Programierer die den Schritt vom Record zur Klasse nicht vollziehen.

Wobei man sagen muss das beim neuen Delphi XE auch einige Neuerungen nicht von TObject kommen, sondern dafür auch Records eingesetzt wurden.

Bis bald Chemiker

[Hansa]

Zitat von xZise:

Moin,
Aber nur dann auf true stelle, wenn danach die Elemente noch bestehen sollen.

Nein, nein, dann muss es auf false stehen. OwnsObjects = true heisst : Beim Freigeben der Liste wird alles enthaltene aufgeräumt/entfernt. Du schreibst das ja selber im nächsten Satz.

Zitat von xZise:

Übrigens wenn ich das richtig verstehe würde ich das so in der Art machen:
[delphi]TMetaData = class(TObject)
Name : string;
[...]
end;

Ne, so ist das nicht richtig. Dürfte zwar gehen, aber zumindest teilweise überflüssig. Ich muss da etwas weiter ausholen, weil es wichtig ist. Insbesondere auch für die, die mit OOP (notfalls Hint lesen) nicht recht was anzufangen wissen. Früher gab es Records. Das waren reine Daten. Üblich war und ist folgende Vorgehensweise (im Prinzip zumindest) : man liest aus einer Datenbank-Tabelle einen Datensatz (^= Record) in eine Variable und hat die Daten dann im Programm zur Verfügung. Ist doch schon mal gut, was ?

Irgendwann kam dann mal irgendwer auf die Idee, dass die Datensätze sowieso gelesen, geschrieben oder sontwas werden müssen. Wieso sollte man eigentlich den Datensätzen nicht gleich sagen, was sie machen können ? Die reinen Daten, also Records hatten plötzlich die Möglichkeit auch "Methoden" zu haben. Das wären dann die heutigen TObject, TClass etc. Typen.

Zurück zur Ausgangsfrage : es geht um Dateiname, Dateigroesse usw., also um ungefähr das, was TSearchRec sowieso hat. Man beachte auch das "Rec" im Namen. In meinem Beispiel benutze ich auch einen Record. Allerdings innerhalb der TObjectList. Diese kriegt notfalls noch Methoden verpasst. Der Record ist starr und braucht keine Methoden. xZise verwendet in seinem Bsp. TObject, obwohl er dafür gar keine Methoden braucht. Da würde es auch ein Record tun. Gut, das dürfte vernachlässigbaren Speicher-Mehrbedarf/Laufzeit bedeuten, im Prinzip aber auch nur Peanuts. 100 Bytes, 1 Millisekunde mehr, was solls ? Allerdings : Record ist mehr oder weniger egal. Wenn das OwnsObjects der TObjectList auch einiges (besser gesagt : sehr viel) selber erledigt, die TObject-Dinger muss ich trozudem mit create erzeugen, was bei Records überflüssig ist.