AW: Vorteile von Records gegenüber Objekten
Zitat:
|
AW: Vorteile von Records gegenüber Objekten
Zitat:
|
AW: Vorteile von Records gegenüber Objekten
Da gibt es z.B. sowas
http://www.delphipraxis.net/122045-b...tml#post848903 welches man sich so kapseln könnte.
Delphi-Quellcode:
Dieser Record ist nun vollkommen kompatibel zur WinAPI
Type
ThMD5 = Record Data: MD5_CTX; Procedure Init; Procedure Update(Input: Pointer; inLen: LongWord); Function Final: MD5_RES; End; oder man nutzt die eingebetetten Record-Methoden. Und am Ende kann man es auch noch ausmotzen, bis zum Geht nicht mehr und es bleibt immernoch kompatibel zur WinAPI. Außerdem läßt sich soein Record direkt und ohne umwege irgendwo abspeichern/übertragen (Stream, Datei, Indy usw.)
Delphi-Quellcode:
Type
ThMD5 = packed Record Data: MD5_CTX; Class Operator Implicit(Value: MD5_CTX): ThMD5;            Inline; Class Operator Implicit(Rec: ThMD5): MD5_CTX;              Inline; Class Operator Implicit(Rec: ThMD5): MD5_DIGEST;           Inline; Class Operator Equal   (Left, Right: MD5_CTX):    Boolean; Inline; Class Operator Equal   (Left, Right: MD5_DIGEST): Boolean; Inline; Class Operator NotEqual(Left, Right: MD5_CTX):    Boolean; Inline; Class Operator NotEqual(Left, Right: MD5_DIGEST): Boolean; Inline; Procedure Init;                                              Inline; Procedure Update(Input: Pointer; inLen: LongWord); Overload; Inline; Procedure Update(Const Input: AnsiString);         Overload; Inline; Procedure Update(Const Input: WideString);         Overload; Inline; Procedure Update(Input: TStream; inLen: LongInt);  Overload; Function  Final: MD5_RES;                                    Inline; Function Calc(Input: Pointer; inLen: LongWord):     ThMD5; Overload; Inline; Function Calc(Const Input: AnsiString):             ThMD5; Overload; Inline; Function Calc(Const Input: WideString):             ThMD5; Overload; Inline; Function Calc(Var Input: TnStream; inLen: LongInt): ThMD5; Overload; Inline; Function CalcFile(Const FileName: WideString; Var Hash: MD5_DIGEST): Boolean; Function asBin:       MD5_DIGEST; Inline; Function asHexString: String; Function asGUID:      TGUID; End; |
AW: Vorteile von Records gegenüber Objekten
Ich denke Records und Objekte haben jeder für sich ihre Daseinsberechtigungen.
Objekte nehme ich immer dann wenn ich auf Konstruktor/Destruktor angewiesen bin. Records verwende ich - wie bisher auch - um Daten zusammen zu fassen. Die "neuen" Records finde ich gut, käme aber nicht auch die Idee auf biegen und brechen unbedingt einen Record anstelle eines Objekts zu nehmen. Eine meiner Favoriten ist eine Clear-Methode in Records, das steigert meiner Meinung nach die Code-Qualität.
Code:
TMyRecord: record
A: integer; B: integer; procedure clear; end; TMyRecord.Clear; begin FillChar(self,SizeOf(self),0); end; TForm1.Button1Click(Sender: TObject) var r1: TMyRecord; begin r1.Clear; end; Bei der Verarbeitung von Datenströmen - seriell oder TCP ist mal egal - haben die "neuen" Records echt Vorteile. CRC-Berechnung, Telegramm-Validierung, Parsing kann alles im Record laufen. Das macht den Code viel übersichtlicher. - arno |
AW: Vorteile von Records gegenüber Objekten
Zitat:
Delphi-Quellcode:
Ich sehe jetzt zum Beispiel auch nichts was mich daran hindern würde dies in FPC zu implementieren (Operatoren für Interfaces wären allerdings wieder interessanter zu implementieren). Wenn mir mal langweilig ist, muss ich mal einen Proof of Concept machen :mrgreen:
type
TIntClass = class Value: Integer; class operator Add(aLeft, aRight: TIntClass): TIntClass; constructor Create(aValue: Integer); end; constructor TIntClass.Create(aValue: Integer); begin Value := aValue; end; var a, b, c: TIntClass; begin // try ... finally wird absichtlich weggelassen a := TIntClass.Create(31); b := TIntClass.Create(11); c := a + b; Writeln('c: ', c.Value); a.Free; b.Free; c.Free; end. Gruß, Sven |
AW: Vorteile von Records gegenüber Objekten
Zitat:
Aber für Operatoren wird eine automatische Speicherverwaltung benötigt und diese ist bei Objekten nicht vorhanden. Nja, bei Systemen mit einem Garbage-Collector, wird oftmals nahezu alles automatisch verwaltet (es sei denn man schaltet dieses geziehlt ab). |
AW: Vorteile von Records gegenüber Objekten
Records als alternative zu DTO (Data Transfer Objects) sind schon legitim, also als reine Datencontainer. Dafür kann man natürlich eine Klasse nehmen, aber hier haben Records einfach weniger Overhead.
Aber erweiterte Records finde ich persönlich bescheuert. Dafür (also für die Funktionalität) sind Klassen da. Wenn ich mein DTO zunächst als Record modelliere, und später merke, das ich die eine oder andere Methode doch benötige, soll ich gefälligst umsteigen oder eine Klasse schreiben, die die benötigten Methoden definiert. Aber ich kann natürlich auch einfach das Record erweitern. Das ist dann im wahrsten Sinne des Wortes "RAPID Prototyping", also schnell schnell angepasst. Leider wird der Code damit unsauber und daher lehne ich das ab. |
AW: Vorteile von Records gegenüber Objekten
Wieso kann man eigentlich nicht primitive Typen um Methoden erweitern? So könnte man z.B. Integer.ToString schreiben wie man das aus anderen objektorientierten Sprachen kennt. (Früher fand ich das ja hässlich, weil es quasi voraussetzt, dass alle Typen sich gegenseitig kennen, aber andererseits ist es doch irgendwie ganz praktisch...)
Oder geht sowas inzwischen? |
AW: Vorteile von Records gegenüber Objekten
Erweitern geht sowieso nicht, da Records und normale Typen keine Vererbung kennen :zwinker:
Aber "Record Helper" für normale Typen wäre schon was schönes :cry: Einen Record, darin einen Integer, noch die ganzen Operatoren und vorallen die implizizen und expliziten Typumwandlungen und schon hast du einen erweiterten Integer. |
AW: Vorteile von Records gegenüber Objekten
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:46 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz