Class vs. Record

[Zwoetzen]

Hi DP'ler,

heute geht es mal nicht um ein spezielles Problem, sondern es wird etwas allgemeiner. Die Frage ist eigentlich schnell gestellt:

Class vs. Record: Wo liegen die Unterschiede und wann sollte man was nehmen?

Gerade bei den erweiterten Records, die Properties und Methoden haben können, drängt sich bei mir immer mehr die Frage in den Vordergrund, wo es da eigentlich noch Unterschiede gibt: Rein von der Syntax sehen die beiden ja (fast) identisch aus ;)

Ein was ist mir schon aufgefallen:
Instanzen von Klassen müssen am Anfang einer zB Funktion selbst angelegt werden, und am Ende auch selbst freigegeben werden. Dementsprechend gibt es Konstrulktoren und Destruktoren.
Record-Variablen legen sich gewissermaßen selbst am Anfang der Funktion an, und man brauch sie nicht freigeben. Entsprechend fehlen Create und Destroy (und entsprechend müsste man glaube mit New() und Dispose() arbeiten, wenn man zB eine Liste füllen will)

Dann muss man bei Klassen beachten, dass man in den Instanzvariablen nur Zeiger stehen hat: Eine Zuweisung kopiert den Zeiger, und nicht das ganze Objekt. Soweit ich weiß, ist es bei Records genau andersrum: Eine Zuweiung dupliziert das Record. (Wenn ich falsch liege, bitte korrigieren ^^)

Ich denke mal, das wird nicht die einzigen Unterschiede sein:
Was gibt es noch zu Beachten, wenn man Records oder Klassen verwendet? Gibt es irgendwelche Vorteile, irgendwelche Nachteile? Gibt es gewisse Situationen, in dem man besser ein Record als eine Klasse verwendet bzw umgekehrt? Oder ist es letztendlich immer Geschmackssache?

Fragen über Fragen, ich hoffe, als Antwort kommt nicht nur die 42 :mrgreen:

MfG Zwoetzen

[Satty67]

Ich hab' 15 Jahre für Datenmengen nur Record's verwendet und Klassen als reine Datencontainer für unnötig angesehen.

Vor einigen Wochen hab' ich mich mehr mit Klassen beschäftigt und in bestimmten Konstellationen eine deutliche Erleichterung festgestellt. Jetzt muss man dazu sagen, das ich mit Delphi 5 noch eine deutlichere Trennung zw. Record und Klasse habe.

Für mich ist der größte (aber auch einzige) Vorteil, das die Daten vorm Lesen/Schreib mit Methoden manupuliert/kontrolliert werden können. Sollte das inzwischen auch mit Record's möglich sein, sehe ich kaum Unterschiede.

Vererbung etc. kommt bei Daten-Klassen, die Record's ersetzten ja nicht so oft vor. Ich hatte zwar auch das Gefühl, das ein Record weniger flexibel in eine andere Klasse eingebunden werden kann, als eine Sub-Klasse, aber das kann auch an meiner noch fehlenden Erfahrung liegen.

Das die Daten beim Record direkt zuweisbar sind und bei einer Klasse nur per Methoden, spricht meiner Meinung nach für den Record. Gerade wenn man große Record-Array's mal sortieren muss, kann das schon was ausmachen. (Wobei man bei der Klasse wohl das ganze Araay implementiert incl. interner Sortier-Methode)

[himitsu]

also inzwischen gibt es da kaum noch Unterschiede ... in Records kann man ja nun auch Funktionen/Prozeduren zur Verarbeitung anlegen.

bezüglich der Speicherung der Daten haben beide ihre Vorteile:
- Klassen lassen sich leicht serialisieren
- Records dafür sehr gut direkt binär verarbeiten/speichern (also wohl besser für Datenübertragung und Binärdateien)

Records lassen sich direkt in andere Structuren/Records einbauen ... Klassen sind dagegen nur erstmal ein Zeiger

Klassen besitzen die Möglichkeiten der Vererbung und lassen somit nachtröglich in ihrer Funktion ändern/erweitern ... Records nicht

wenn es um Geschwindigkeit und Datengröße geht, dann sind Records etwas besser ... bei den Klassen kommt ja noch ein größerer Verwaltungsakt dazwischen, auch wenn der nicht all zuviel Zeit in Anspruch nimmt (macht also wirklich nur etwas aus, wenn es um sehr viele Transaktionen/Aufrufe und um je Mikrosekunde geht)




Mein himXML-Projekt hatte ich auch mal Recordbasierend angefangen (da ich es sehr klein und schnell halten wollte), es aber aus verschiedenen Gründen doch nach Objekten umgestellt ... vorallem ist es nicht (einfach) möglich verschiedene Records an einen Funktionsparameter zu übergeben.
Dagegen hab ich 'ne andere Spielerrei komplett in Records gehalten, da ich die Vorteile der Klassen nicht brauchte und mir die Records mehr Vorteile boten.


PS: Operatoren gibt es in delphi nur bei Records, also wenn man diese nutzen möchte, dann geht es nur über Records (oder eine etwas umständlichere Record-Klassen-Kombi)

[p80286]

Hallo Zusammen,

da ich wohl extrem konservativ bin, stehe ich Klassen nicht sehr wohlwollend gegenüber, vielleicht habe ich sie bisher auch nicht wirklich benötigt.

darum nur zwei Einlassungen.
- In Klassen muß man nicht zwangsläufig mit Methoden auf Inhalte zugreifen, aber es ist vom Konzept her auf jeden Fall vorzuziehen.
- Records sind durchaus erweiterbar. z.B. ist folgendes Konstrukt durchaus anwendbar

Delphi-Quellcode:

  tpasatz = packed record
              pnr    : pnrtyp;                    
              stat1  : char;                      
              stat2  : char;                      
             .......
              adddata: array [1..37] of char;     
            end;
  tpsatz2 = packed record
              PDAT   : tpasatz;                   
              VERS   : verstyp;             {verstyp ist ebenfalls ein Record}      
              CRLF   : array [1..2] of char;
            end;

wobei der besondere Charme dieser Lösung darin lag, das die ursprünglichen Verarbeitungsroutinen (tpsatz) durch die Erweiterung nicht verändert werden mußten.

Gruß
K-H

[jfheins]

Was ich an Klassen sehr schön finde ist die Kapselung (auch Encapuslation) :)

Wenn ich Daten in C in einer Liste halten wollte, musste ich mich erst für eine Variante entscheiden (linked List oder dyn. Array).
Dann eine Art Info-Teil schreiben

Code:

struct
{
  void^ Location; // Location: Pointer;
  int count; // count: Integer;
}

und dann ein paar Zugriffsmethoden die dann z.B. ein Element lieferten.

In C# hab ich dann nur ein List<T> (generische Liste) in der dann die ganze Funktionalität drin ist. z.B. Sortieren gibts direkt oben drauf :)
Und wenn ich z.B. mal nicht normal sortieren möchte, sondern z.B. eine stabile Sortierung brauche, kann ich einfach die Klasse ableiten und verändern - und trotzdem wir sie noch überall akzeptiert wo eine List<T> verlangt wird :)
(Ich hab zwar noch nie sowas abgeleitet, aber schematisch müsste es so gehen ;) )

Ich weis, der Vergleich C zu C# ist etwa so wie vom Urgroßvater zum Urenkel, aber ich hoffe ihr wisst was ich meine :stupid:

[himitsu]

Zitat:

Zitat von p80286

- Records sind durchaus erweiterbar. z.B. ist folgendes Konstrukt durchaus anwendbar

OK, vom Dateninhalt her, aber nicht vom Zugriff ... der enthaltene/untergeordnete Record ist dann nicht mehr "direkt zugreifbar.

tpasatz.stat1 ist dann, in der Ableitung, nicht mehr via tpsatz2.stat1 erreichbar, sondern nur noch via tpsatz2.tpasatz.stat1 (OK, man könnte sich über ein Property eine Umleitung einrichten, aber das wäre ja ein Umweg)

[quendolineDD]

Du hast mit Klassen mehr Flexibilität.
Ich schmeisse mal ein paar Begriffe der OOP in den Raum:
Polymorphie, Kapselung und Vererbung.

Wenn du jetzt zB eine Prozedur hast, von der du die Farbe eines Fahrzeuges haben möchtest, könntest du sicher für jeden Record einer bestimmten Fahrzeugvariante übergeben.
Aber einfacher ist es doch, du hast eine Oberklasse Fahrzeug und dann Subklassen Auto, Motorrad usw. Somit kannst du alle in direkter Vererbungslinie stehenden Subklassen übergeben.
Weiterhin kannst du durch die Datenkapselung beiweitem besser auf die Sachen zugreifen. DU kannst durch deine Klassendefinition entscheiden wie und wann auf die Daten zugegriffen wird.
Weiterhin finde ich gerade die Vererbung sinnvoll. So kannst du allgemeingültige Oberklassen stets zu speziellen Subklassen ableiten und die vererbten Methoden entweder beibehalten oder manipulieren. So Sache wie Interfaces usw. kannst du mit Records ja gar nicht nutzen.

Da ich auch nebenbei mit C#/Java programmiere, bin ich eh der OOP verfallen (Java ist nahezu durch und durch OO und C# zu 100%). Es erleichtert die Nutzung, verinfacht die Erweiterbarkeit, Wartung und den Austausch von Teilen der Software.

[himitsu]

Zitat:

Polymorphie, Kapselung und Vererbung

ja und wenn man gerade dieses nicht benötigt, dann kann man auch (manchmal sogar optimaler) Records verwenden.


Also im Grunde hat beides seine Vorteile und man muß im Einzelfall selbst abwegen,
was sich da besser macht und man dann am Ende bevorzugt.

[Luckie]

Records kennen, glaube ich, auch keine Sichtbarkeiten, d.h. in Records ist alles öffentlich.

[himitsu]

Records kennen Sichtbarkeiten :stupid:

also mindestens Private und Public
aber Strict kennen sie (glaub ich grad) nicht.

[quendolineDD]

Ich würd meinen das in kleinen Projekten Records angemessen sind aber in größeren Sachen der Overhead von Klassen effektiv gekillt wird.
Das Records Sichtbarkeiten kennen wusste ich auch noch nicht.

[himitsu]

Zitat:

Zitat von quendolineDD

Das Records Sichtbarkeiten kennen wusste ich auch noch nicht.

Beispiele siehe MiniMathLib und TBigInt


hab's grad nochma getestet:
Strict Private, Private und Public ist in Records möglich.
Strict Protected, Protected und Published nicht.

das mag der Compiler alles:

Delphi-Quellcode:

Type TTestRec = Record
  Strict Private
  Private
  //Strict Protected
  //Protected
  Public
  //Published
End;

[sirius]

Zitat:

Zitat von himitsu

Strict Protected, Protected und Published nicht.

Ist ja auch nicht sinnvoll, wenn es keine Vererbung und RTTI gibt.

[himitsu]

Typ-Infos gibt es aber auch teilweise zu Records :angel2: die werden doch z.B. zum Initialisieren/finalisieren verwendet.


nja, aber zumindestens .... Records kennen vererbung und das war ja grad die Frage :mrgreen:

[p80286]

@ Himitsu,

in #6 hast du geschrieben

Zitat:

tpasatz.stat1 ist dann, in der Ableitung, nicht mehr via tpsatz2.stat1 erreichbar, sondern nur noch via tpsatz2.tpasatz.stat1

das ist korrekt, da aber nur bei den entsprechenden Aufrufen der Variablenname geändert werden muß und in der Variablendefinition, ist das nicht sehr aufwendig falls man ein paar rudimentäre Regeln eingehalten hat (suchen und ersetzen).
Wenn ein Record 40 Felder hat und ich 40 mal eine Put und Get definieren soll, frag ich mich schon wo der Fortschritt von OOP liegen soll.
Nein keine Grundsatzdiskussion, es gibt bestimmt gute Gründe für OOP, aber ich hab sie in meiner Praxis noch nicht gefunden.

@quendolineDD

Zitat:

Du hast mit Klassen mehr Flexibilität.
Ich schmeisse mal ein paar Begriffe der OOP in den Raum:
Polymorphie, Kapselung und Vererbung.

und wer braucht das?
Polymorphie soweit ich weiß "Vielgestaltigkeit", erreiche ich mit absolut oder in der Recorddefinition mit case.
Kapselung ist nicht (aber wofür ist es gut?)
Vererbung hab ich genutzt (sollte man aber nicht übertreiben)

(Achja falls jemand fragt wofür Records gut sind, da hat man die Daten, die zusammen gehören unter einem Namen im Zugriff. Bei Klassen ist das irgendwie ähnlich)

Gruß
K-H

[hanspeter]

Zitat:

Zitat von Zwoetzen

Class vs. Record: Wo liegen die Unterschiede und wann sollte man was nehmen?

Klassen haben einen Vorteil, wenn die Datenbestände in Listen gehalten werden. Etwas weniger Aufwand und Schreibarbeit.


ptr := TDatensatz.Create
Liste.Add(ptr);

und später ptr.Free;

Der Zugriff auf ein Element der Liste

ptr := Liste(i);

Records muss ich entweder in einem Array verwalten oder den Speicherplatz mit GetMem und Freemem selbst verwalten.
Eine Klasse wird immer über einen Zeiger angesprochen (Delphi und C#).
Bei Records muss ich wissen, ob ich eine Kopie des Records oder einen Zeiger auf einen Record handle.

Gruß
Peter

[Cyf]

Zitat:

Zitat von hanspeter

Zitat:

Zitat von Zwoetzen

Class vs. Record: Wo liegen die Unterschiede und wann sollte man was nehmen?

Klassen haben einen Vorteil, wenn die Datenbestände in Listen gehalten werden. Etwas weniger Aufwand und Schreibarbeit.


ptr := TDatensatz.Create
Liste.Add(ptr);

und später ptr.Free;

Der Zugriff auf ein Element der Liste

ptr := Liste(i);

Records muss ich entweder in einem Array verwalten oder den Speicherplatz mit GetMem und Freemem selbst verwalten.
Eine Klasse wird immer über einen Zeiger angesprochen (Delphi und C#).
Bei Records muss ich wissen, ob ich eine Kopie des Records oder einen Zeiger auf einen Record handle.

Gruß
Peter

Du kannst genauso eine Liste mit Zeigern auf Records verwalten und die Records mit New und Dispose (GetMem und FreeMem sind veraltet) dynamisch erzeugen. Das ist kein wirkliches Argument für oder gegen OOP.
Der Vorteil von OOP liegt imho darin, das man alles was man mit Daten machen kann an einer Stelle gebündelt hat und man über RTTI verfügt, der Nachteil ist der Overhead der durch den längeren Erzeugungs-/Freigabecode und die RTTI entsteht.

[himitsu]

der Vorteil beim Record ist halt, daß man (wenn man bestimmte Regeln einhält) mit einem Zeiger auf diesen Record und mit direktem Zugriff auf den Inhalt, alles anstellen kann, was man mag.

[quendolineDD]

Und da wirds mal schnell gefährlich, wenn die Zeiger ins leere zeigen...

[mkinzler]

Zitat:

Zitat von quendolineDD

Und da wirds mal schnell gefährlich, wenn die Zeiger ins leere zeigen...

Das gilt aber auch für Objektreferenzen

[stoxx]

die wahre Schönheit und Eleganz des objektorientierten Programmierens wird sich Dir mit Records allerdings nicht erschließen, auch wenn sich eine einfache Grundklasse sicherlich mit Records oder einer Klasse realisieren ließe ...