Vorteile eines Records gegenüber einer eigenen Klasse?

[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.