Vorteile eines Records gegenüber einer eigenen Klasse?

[malo]

Welche Vorteile haben Records eigentlich gegenüber Klassen? Man kann doch mit einer Klasse genauso umgehen, wie mit einem Record, nur, dass Klassen vielseitiger sind, oder? Oder sehe ich das irgendwie falsch? Verbrauchen Klassen vielleicht mehr Speicher oder so als Redcords? Ich find nämlich die Records ziemlich unsinnig, da man eine Klasse ja auch wie ein Record behandeln kann ;)

[Neutral General]

Ich denke mal ein Record verbraucht nicht so viel Speicher weil eine Klasse ja noch das ganze TObject Gerümpel hat was man nicht immer braucht...

Wenn ich jetzt Quatsch rede sagt es mir bitte :mrgreen:

[Oxmyx]

Einen Record kann man statisch instantiieren, eine Klasse nicht.

Deshalb benutzt man Records meist, um Verbunddatentypen zu erstellen.

[Fourcorner]

Hallo

Zitat:

Welche Vorteile haben Records eigentlich gegenüber Klassen?

Ein Record ist nur ein Speicherplatz im Speicher. Eine Klasse hingegen kann neben den Record auch Funktionen und Proceduren aufnehmen. Zudem können Klassen von anderen Klassen abgeleitet werden.

Zitat:

Ich find nämlich die Records ziemlich unsinnig, da man eine Klasse ja auch wie ein Record behandeln kann

Nicht ganz. Probiere mal folgenden Record in ein Klasse umzuschreiben:

Delphi-Quellcode:

var Verein: Array of record
  Bez: String;
  LSV: String;
  Land: String;
  Meldung: Array of record
    Name: String;
    Jahrgang: String;
    Geschlecht: String;
    Start: Array of record
      WKN: integer;
      MZeit: String;
    end;
  end;
  MeldungSt: Array of record
    Name: String;
    Start: Array of record
      WKN: integer;
      MZeit: String;
    end;
  end;
  Namenliste: Array of record
    Name: String;
    Jahrgang: String;
    Geschlecht: String;
  end;
end;

Du siehts, der Vorteil an einem Record ist, dass er nochmals "unterteilt" werden kann. Eine Klasse kann natürlich auch einen Record enthalten, jedoch ist die, wenn man nur Daten speichern will, umsonst.

[Pseudemys Nelsoni]

erstens wie schon gesagt ist dann unsinniges zeug das man nicht brauch mit in einer klasse.
Ausserdem wäre es ziemlich doof wenn man einer funktionen einen rekord(in diesem fall klasse) übergeben müsste den man vorher erst kreieren/zerstören muss....gibts zwar auch, aber egal

[Robert Marquardt]

Ein Record ist passiv, hat also nur Daten und keine Methoden.
Will man nur die Daten verarbeiten so ist es naterlich viel effizienter Records zu nehmen.
Ein Grossteil der Daten wird ja nur herumgeschubst.

Manche Sprache wie Smalltalk ist extrem indem jedes Datenelement ein Objekt ist.
1 + 2 ist also 1.PlusMethode(2).

[Sanchez]

Zitat:

Zitat von Pseudemys Nelsoni

Ausserdem wäre es ziemlich doof wenn man einer funktionen einen rekord(in diesem fall klasse) übergeben müsste den man vorher erst kreieren/zerstören muss....gibts zwar auch, aber egal

Warum?
Mit Klassen ist doch eine viel schönere Kapselung der Funktionalität möglich. Die Funktionen sind dann dort, wo sie hingehören. Ich verwende Records großteils dazu, um Daten zwischen Verschiedenen Klassen auszutauschen.

[MaBuSE]

Records gab es schon in Turbo Pascal 3.0
Damals war Pascal noch nicht objektorientiert.

Das änderte sich erst mit der Version Turbo Pascal 5.5
Der Unterschied zwischen TP5 und 5.5 waren eigentlich nur eine Hand voll Schlüsselwörter.
Eines davon war "object" ;-)

Trotzdem haben Records noch ihre Daseinsberechtigung.
Es gibt viele Dinge die mit einem Record einfach zu erledigen sind.

Aber auch komplexe Aufgeben wie Variante Teile in Records lassen leicht darstellen:

Delphi-Quellcode:

type
  TPerson = record
  FirstName, LastName: string[40];
  BirthDate: TDate;
  case Citizen: Boolean of
    True: (Birthplace: string[40]);
    False: (Country: string[20];
            EntryPort: string[20];
            EntryDate, ExitDate: TDate);
  end;

oder wenn man wissen will, wie z.B. ein Extended intern im Speicher abgelegt ist, kann man das einfach erledigen:

Delphi-Quellcode:

...
type
  myReal = record
             case Boolean of
               True: (Zahl: Extended); // Extended belegt intern 10 Bytes
               False: (Speicher: array[0..9] of Byte); 
            end;
...
procedure TForm1.Button1Click(Sender: TObject);
var
  r: myReal;
  i: Integer;
  s: string;
begin
  // Zahl zuweisen
  r.Zahl := 7.5;

  // Speicher, der von Zahl belegt wird hexadezimal ausgeben
  s := '';
  for i := 0 to 9 do
  begin
    s := s + IntToHex(r.Speicher[i], 2) + ' ';
  end;
  Label1.Caption := s;
end;
...

Delphi 7 Hilfe

...Wie bereits erwähnt, erfüllen variante Teile noch eine zweite Aufgabe. Sie können dieselben Daten so behandeln, als würden sie zu unterschiedlichen Typen gehören. Dies gilt auch in den Fällen, in denen der Compiler eine Typumwandlung nicht zulässt. Wenn beispielsweise das erste Feld einer Variante einen 64-Bit-Real-Typ und das erste Feld einer anderen Variante einen 32-Bit-Integer-Wert enthält, können Sie dem Real-Feld einen Wert zuweisen und anschließend die ersten 32 Bits als Integer-Wert verwenden (indem Sie sie beispielsweise an eine Funktion übergeben, die einen Integer-Parameter erwartet).

Records können ja auch Objekte enthalten:

Delphi-Quellcode:

...
type
  TFormRec = record
    MainForm: TForm1;
    ClientForm: TForm1;
    blabla: string;
  end;

var
  FormRec: TFormRec;
...
procedure TForm1.Button3Click(Sender: TObject);
begin
  FormRec.MainForm := TForm1.Create(Application);
  FormRec.ClientForm := TForm1.Create(Application);
  FormRec.MainForm.Color := clRed;
  FormRec.ClientForm.Color := clBlue;
  FormRec.MainForm.Show;
  FormRec.ClientForm.Show
end;

[Chewie]

Klar, bei manchen Sachen machen variante Teile in Records Sinn, in manchen Fällen wäre das mit polymorphen Objekten weit einfacher zu regeln. Ein gutes Beispiel sei hierfür das ganze NMHDR-Gedöns, wo man einen Record-Zeiger in 10 verschiedene erweiterte Records casten darf...

[Binärbaum]

Records sollte man verwenden, wenn es darum geht, schon strukturierte Daten zu speichern (z.B. Adressdaten). Da braucht man dann auch keine Klassen. Klassen sind aber dann nützlich, wenn man für die Daten bestimmte Funktionen/ Prozeduren braucht, die immer wieder auf diese Daten zugreifen. Da sind Klassen sinnvoller als Records.

MfG
Binärbaum

//Edit: immer diese Rechtschreibfehler

[Robert_G]

Zitat:

Zitat von Binärbaum

Records sollte man verwenden, wenn es darum geht, schon strukturierte Daten zu speichern (z.B. Adressdaten). Da braucht man dann auch keine Klassen. Klassen sind aber dann nützlich, wenn man für die Daten bestimmte Funktionen/ Prozeduren braucht, die immer wieder auf diese Daten zugreifen. Da sind Klassen sinnvoller als Records.

MfG
Binärbaum

//Edit: immer diese Rechtschreibfehler

Gerade STRUKTURIERTE Informationen haben in records nichts zu suchen. ;)
Strukturiere Infos lassen sich doch viel schöner, flexiber und performanter in Instanzen von Klassen abbilden, die Felder von Instanzen einer Klasse besitzen.
Wenn man nicht gerade mit einem Pointer auf einen Vorschlaghammer (PSledgeHammer = ^TSledgeHammer; :mrgreen: ) alle wild umherirrenden Pointer auf Records zusammenhaut, muss man in Kauf nehmen dass sie STÄNDIG KOPIERT werden!
Primitive Typen machen nur Sinn, wenn sie unter einer gewissen Größe bleiben (ca. 10-20 Bytes). Ansonsten verliert man beim Kopieren zuviel Performance gegenüber Objektzeigern (4 Bytes). Zum Bsp: Niemand wird eine Klasse verwenden um einen Int zu benutzen. :mrgreen:
Records haben keine Konstruktoren, Destruktoren, Methoden, Properties (sind zwar auch Methoden...) das alleine macht sie schon komplett unnütz um strukturierte Information zu halten.
Die Tatsache, dass man sie nicht voneinander ableiten kann sollte sie komplett verbannen. ;)

Sicher haben Records ihre Daseinsberechtigung, wie will man diese ganzen ekligen Win32 Funktionen ohne Records verwenden? :gruebel:
Das heißt aber nur, dass man diese Zugriffe in Klassen verpacken kann. Records oder API-Aufrufe haben IMHO in der eigentlichen Anwendung nix zu suchen. ;)

Ich persönlich gehe soweit, dass ich Arrays in 99% aller Fälle durch Listen/Collections ersetze. Die kann man schließlich ableiten, wachsen/schrumpfen lassen und mit Methoden, Events und Properties schmücken. Arrays könen nix außer Elemente eines Types zu halten...

Das waren nur meine 2 Cents, zum Thema Vergewaltigung einer OOP-Sprache mit unflexiblen mittelalterlichen Herangehensweisen. ;)
Vielleicht bin ich auch einfach zu sehr .Net-versaut... :mrgreen:

[Hansa]

Die Frage an sich könnte auch heißen : "Was schmeckt besser : Äpfel, Birnen oder ein Record ?" :mrgreen:

Was man machen kann, heißt noch lange nicht, daß man es machen muß oder sogar soll !! Records kommen aus dem Bereich Datenbank. Man mußte sich pro Datensatz eine Struktur ausdenken, die eben strukturiert ist. Z.B. ging es darum, ein Datum mit Tag, Monat und Jahr abzubilden. Wobei nur integer zur Verfügung stand. Deshalb ein Record mit 3 Untervariablen als integer. Später wurde das dann noch komprimiert usw.

Zu jedem Datum jetzt noch eigene Behandlungsroutinen mitzuschleppen und abzuspeichern ? Was soll das ? Das geht anders viel eleganter. Nun kommen noch Listen Arrays usw. ins Spiel. Gut, ich bleibe mal bei dem Datum : Ich speichere also in der DB einen Monat als Zahl, z.B. 2 für Februar. Der Anwender will nun aber nicht die 2 haben, sondern das Wort "Februar". Was liegt da näher, als die Monatsnamen in einem Array zu speichern ?

Besteht der leiseste Zweifel daran, daß es demnächst nicht mehr 12, sondern 13 Monate oder mehr gibt, so würde ich auch Listen verwenden. Vorher aber nicht.

Lange Rede kurzer Sinn :

Überlegen, ob sich und wenn, dann was sich ändern kann. Bleibt alles so wie gehabt, dann Arrays, Records und ordinale Typen. Geht es ums speichern von Daten dann sowieso. Im Programm selber macht es aber schon Sinn eventuell mit Objekten zu hantieren. Wer nicht mal grundsätzlich OOP einsetzt für ein etwas größeres Programm, der ist selber Schuld und kann letztenendes sowieso einpacken. Aber auch dann gilt, sich das genau zu überlegen, wo was nützlich ist.

[Jens Schumann]

Zitat:

Zitat von Hansa

Die Frage an sich könnte auch heißen : "Was schmeckt besser : Äpfel, Birnen oder ein Record ?" :mrgreen:

So hat jeder berechtigterweise seine eigenen Vorlieben und Paradigmen. Deshalb geht es hier nicht um richtig oder falsch!!! In diesem Fall gehöre ich der gleichen Denkschule an wie Robert_G. Irgendwie empfinde ich es logischer, wenn ein Integer wie unter .net seine ToString() Methode gleich mitbringt anstatt eine "externe" Methode (IntToStr) dafür zu verwenden.

Zitat:

Zitat von Hansa

Was man machen kann, heißt noch lange nicht, daß man es machen muß oder sogar soll !! Records kommen aus dem Bereich Datenbank. Man mußte sich pro Datensatz eine Struktur ausdenken, die eben strukturiert ist. Z.B. ging es darum, ein Datum mit Tag, Monat und Jahr abzubilden. Wobei nur integer zur Verfügung stand. Deshalb ein Record mit 3 Untervariablen als integer. Später wurde das dann noch komprimiert usw.

Gerade in diesem Bereich habe ich die Erfahrung gemacht, dass es wesentlich effektiver ist die Datensatzsturktur auf Objekte abzubilden. Gerade wg der Möglichkeiten der Events und Vererbung. In meinem derzeitgen Projekt mache ich massiv davon gebrauch.

Zitat:

Zitat von Hansa

Zu jedem Datum jetzt noch eigene Behandlungsroutinen mitzuschleppen und abzuspeichern ? Was soll das ? Das geht anders viel eleganter. Nun kommen noch Listen Arrays usw. ins Spiel. Gut, ich bleibe mal bei dem Datum : Ich speichere also in der DB einen Monat als Zahl, z.B. 2 für Februar. Der Anwender will nun aber nicht die 2 haben, sondern das Wort "Februar". Was liegt da näher, als die Monatsnamen in einem Array zu speichern ?

Hier hätte ich in der Datenbank eine Tabelle mit den Monatsnamen und würde beim SELECT die Nummer gegen den Monatsnamen austauschen.

Zitat:

Zitat von Hansa

Besteht der leiseste Zweifel daran, daß es demnächst nicht mehr 12, sondern 13 Monate oder mehr gibt, so würde ich auch Listen verwenden. Vorher aber nicht.

In der Buchhaltung gibt es 13 Monate. Manchmal soger 14 :cyclops:

[SirThornberry]

ohne Records könnte man man einen Großteil der ApiAufrufe nicht nutzen da eben eine Struktur erwartet wird bzw. ein Pointer auf diese Struktur. natürlich könnte man an dieser stelle auch ein PChar übergeben der die gewünschte länge hat und diesen dann im Hauptprogramm auseinander stückeln, aber das bringt mehr aufwand als nutzen.
Diesen Apifunktionen Objecte zu übergeben geht nicht da die Objecte sich schon zwischen den Delphiversionen unterscheiden und von DLL's die in anderen Programmiersprachen geschrieben wurden erst recht nicht verwendet werden können.

Oder wie wöllte man ohne Records zum Beispiel folgende Funktionen benutzen

Code:

BOOL GetWindowPlacement(
    HWND hWnd,   // handle of window
    WINDOWPLACEMENT *lpwndpl    // address of structure for position data
   );

Code:

BOOL GetWindowRect(
    HWND hWnd,   // handle of window
    LPRECT lpRect    // address of structure for window coordinates
   );

Man könnte in diesen Fällen eben nur den Umweg über PChars gehen und diese dann später zerpflücken was wie schon geschrieben bissl zu viel aufwand wäre.

[Robert_G]

Zitat:

Zitat von Robert_G

Sicher haben Records ihre Daseinsberechtigung, wie will man diese ganzen ekligen Win32 Funktionen ohne Records verwenden? :gruebel:
Das heißt aber nur, dass man diese Zugriffe in Klassen verpacken kann. Records oder API-Aufrufe haben IMHO in der eigentlichen Anwendung nix zu suchen. ;)

[SirThornberry]

Zitat:

Das heißt aber nur, dass man diese Zugriffe in Klassen verpacken kann. Records oder API-Aufrufe haben IMHO in der eigentlichen Anwendung nix zu suchen

:gruebel: Ist das jetzt ironie? Wenn ich einen Record in einer Klasse hab ist er somit doch auch in meiner Hauptanwendung :?

[Jens Schumann]

Zitat:

Zitat von SirThornberry

Zitat:

Das heißt aber nur, dass man diese Zugriffe in Klassen verpacken kann. Records oder API-Aufrufe haben IMHO in der eigentlichen Anwendung nix zu suchen

:gruebel: Ist das jetzt ironie? Wenn ich einen Record in einer Klasse hab ist er somit doch auch in meiner Hauptanwendung :?

Nein, das ist keine Ironie. Robert_G möchte damit sagen, dass man die API-Aufrufe in Klassen kapseln sollte ( macht die VCL auch). Dann kann der Anwender der Klasse wie gewohnt in OOP Strukturen denken.

[SirThornberry]

aber die klasse welche die API-Funktion kapselt verwendet doch auch records..

[Jens Schumann]

Zitat:

Zitat von SirThornberry

aber die klasse welche die API-Funktion kapselt verwendet doch auch records..

Ja - wie sollte es denn sonst funktionieren. Aber darum geht es gar nicht. Es geht darum, dass der Anwender der Klasse sein OOP-Denkmodell bei der Programmierung nicht verlassen muss. Das macht das kapseln von API-Aufrufen in Klassen sinnvoll.

[SirThornberry]

ok, ich hab die ausgangsfrage so verstanden ob records überhaupt noch gebraucht werden.
Desweiteren finde ich es bissl übertriebeben für

Delphi-Quellcode:

BOOL GetWindowRect( 
    HWND hWnd,   // handle of window 
    LPRECT lpRect    // address of structure for window coordinates 
   );

eine Klasse zu schreiben. das würde doch die ganze Anwendung nur übelst ausbremesen wenn ich jeden aufruf von "BeginPaint" etc. in eine Klasse packe. Dann würde aus einer Zeile für den Aufruf mindestens 3 werden weil ich vorher noch eine instanz erstellen muss und diese auch wieder freigeben.