Einzelnen Beitrag anzeigen

efknarf

Registriert seit: 12. Jan 2007
Ort: Erfurt
21 Beiträge
 
Delphi 2007 Professional
 
#26

Re: Methoden nun doch für Records?

  Alt 10. Nov 2007, 14:18
Hallo,

nachdem ich nun testweise ein Project von mir mit diesen Records ausgestattet habe, bin ich zu folgendem Schluß gekommen:
1. Viele Objecte ließen sich komplett ersetzen ohne daß die Lauffähigkeit des Programmes gestört oder mehr Speicher gebraucht wurde. Try-except- bzw. try-finally-Blöcke entfielen auch zu einem Großteil und die Verwaltung wurde einfacher, was zu einer kompakteren Unit führte. Auf diese Weise deklarierte Enumeratoren beschleunigten den Zugriff auf die zugehörigen Daten enorm. Danke für den Tipp.

2. Unbeabsichtigte Veränderung eines Datenrecords kann zwar wirkungsvoll behindert, aber nicht verhindert werden. Bei einer Deklaration eines Typs nach folgendem Rezept:
Delphi-Quellcode:
unit unit1

interface

type
  TTest = Record
  private
    FItem1: Integer;
    FItem2: Integer;
  public
    Item1: Integer read FItem1;
    Item2: Integer read FItem2;
  end;
  
  TWriteTest = Record
  private
    FTest: TTest;
  public
    property Item1: Integer read FTest.FItem1 write FTest.FItem1;
    property Item2: Integer read FTest.FItem2 write FTest.FItem2;
  end;
Delphi-Quellcode:
unit unit2

interface

uses
  Unit1;

type
  TNewTest = type Unit1.TTest;

implementation

procedure TueDies(var T: TNewTest);
begin
  T.FItem1:=25; //hier wird bei FItem1 eine Fehlerlinie angezeigt
  // T.Item:=25 ist nicht möglich und erzeugt eine Fehlermeldung
end;

(* Diese Art der Datenmanipulation funktioniert, sollte aber nicht verwendet werden *)
procedure SetData(var T: TTest; Item1,Item2: Integer);
var Temp: TNewTest absolute T; //Temp belegt den selben Adressbereich wie T;
begin
  Temp.FItem1:=Item1; //rote Linie unter FItem1
  Temp.FItem2:=Item2; //rote Linie unter FItem2
end;
stehen nun in den in Unit2 deklarierten Prozeduren auch alle als Privat deklarierten Felder und Methoden zur Verfügung, die den neuen Datentyp verwenden. Der Editor von Delphi unterstreicht diese Felder zwar mit einer roten Linie, aber den Compiler interessiert das nicht. Über ein Typecasting kann nun auch der ursprüngliche Record verändert werden. Allerdings entspricht das nicht einem sauberen Programmierstil und ich rate deshalb dringend davon ab, in Hinblick darauf, daß in späteren Versionen von Delphi dieser Bug - ist das einer? - beseitigt werden könnte. Für diesen Zweck sollte man den Recordtyp Unit1.TWriteTest verwenden.

3. Prozedurale Zeiger (Methodenzeiger bzw. Prozedurzeiger) auf die "Methoden?" eines Records konnte ich nicht erstellen, ohne einen internen Fehler auszulösen und mein Delphi zum Absturz zu bringen. Eigentlich ja auch logisch, da Records ja keine Objecte sind (im eigentlichen Sinne) und demzufolge eigentlich auch keine Methoden haben können.

4. Die Lesbarkeit und die Wartung wird einfacher, da die meisten manipulativen Prozeduren und Funktionen nun in diesem Record gekapselt werden können.

5. Beim Aufruf der Programmierhilfe im Editor von Delphi (ich meine die ListBox, in welcher man die Prozeduren und Eigenschaften von Objecten auflisten ud auswählen kann), listet nicht mehr hunderte Eigenschaften und Methoden auf, die kein Mensch braucht, sondern nur diese, die in diesem Record gekapselt sind.

6. Dennoch sollte man die Warnungen, welche hier von den verschiedenen Usern gegeben wurden nicht unbeachtet lassen, wenn man solche Records verwendet. Wer abwärts-kompatibel bleiben muß, der darf natürlich diese Records nicht verwenden. Für alle Anderen, die diese Art der Deklaration noch nicht kennen, empfehle ich, diese Records einfach mal auszuprobieren.
Auch nicht unbeachtet lassen darf man die zusätzliche Stackbelastung durch solche Records, da sie meistens als lokale Variablen in Prozeduren Verwendung finden und in diesem Falle nicht auf dem Heap abgelegt werden.

7. Ein als const-Parameter übergebener Record kann trotzdem über seine manipulativen Methoden verändert werden. Also Vorsicht, wenn ein solcher Record in einem Object Verwendung findet und keine Vorkehrungen für versehentliches Ändern getroffen sind. In diesem Falle nämlich bekommt das Besitzer-Object von dieser Veränderung nichts mit.

Ich für meinen Teil, und das ist nur meine persönliche Meinung und Bedarf keiner weiteren Kommentare, finde diese Art der Record-Deklaration einfach Spitze. Da mir Delphi2006 nicht zur Verfügung steht, war es für mich nicht möglich, dieses Konstrukt schon eher auszuprobieren. In meiner Version funktionierte es einwandfrei, bis auf den Prozeduralen-Zeiger-Crash. Aber vlt. hat ja jemand eine Idee, wie man dieses Problem umgehen kann.

Bye

und ein schönes Wochenende an alle.

Frank
  Mit Zitat antworten Zitat