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.