Automatischer Konstruktor in Record

Nano-Ware · Beiträge: 394 Erhaltene Danke: 7

Hey,

mein Record sieht so ähnlich aus:

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:

type
  TPerson = record
    Vorname: string;
    Nachname: string;
    Anschrift: string;
    EMails: TStringList;
  end;

Wie man erkennen kann, beinhaltet das Record ein Objekt TStringList. Kann ich irgendwas hinzufügen, dass direkt bei der Variablenzuweisung, also :

Franz : TPerson

Der Konstruktor der TStringList aufgerufen wird? Also dass ich mir

Franz.Emails.Create

ersparen kann.

Danke!

jasocul · Verfasst: Mi 25.04.12 14:20

Automatisch? Meines Wissens nicht.
Du kannst aus deinem Record natürlich eine Klasse machen mit Constructor (und Destructor), in der dann deine Stringlist erzeugt (und wieder freigegeben) wird.

Allerdings musst du dann diese Klasse zur Laufzeit erzeugen. Du verschiebst das Problem also nur.

bummi · Verfasst: Mi 25.04.12 18:34

ein bisschen was geht, schön ist es aber IMHO nicht

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:

type
  TPerson = record
    private
    FEMails: TStringList;
    function GetEmails: TStringList;
    public
    Vorname: string;
    Nachname: string;
    Anschrift: string;
    Property EMails:TStringList read GetEmails;
  end;

  TPersonenArray=Array of TPerson;
  TForm2 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
     FPersonenArray:TPersonenArray;
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form2: TForm2;

implementation

{$R *.dfm}
function TPerson.GetEmails: TStringList;
begin
    if not Assigned(FEMails) then FEMails:=TStringList.Create;
    Result := FEMails;
end;

procedure TForm2.Button1Click(Sender: TObject);
begin
     SetLength(FPersonenArray,2);
     FPersonenArray[0].Nachname := 'Test';
     FPersonenArray[0].Emails.Add('Test@test.xxx');
     FPersonenArray[0].Emails.Add('Test2@test.xxx');
     FPersonenArray[1].Nachname := 'Nase';
     FPersonenArray[1].Emails.Add('Nase@test.xxx');
     FPersonenArray[1].Emails.Add('Nase2@test.xxx');
     Showmessage(FPersonenArray[0].Emails.Text);
     FPersonenArray[0].Emails.Free;
     FPersonenArray[1].Emails.Free;
end;

_________________
Das Problem liegt üblicherweise zwischen den Ohren H₂♂
DRY DRY KISS

Blup · Beiträge: 174 Erhaltene Danke: 43

Das Problem ist hier auch die automatische Freigabe der Stringliste, wenn der Gültigkeitsbereich der Variablen verlassen wird. Das lässt sich eigentlich nur mit einem Interface automatisieren.

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:

type
  IStringListOwner = interface(IInterface)
    function GetStringsList: TStringList;
  end;

  TStringListOwner = class(TInterfacedObject, IStringListOwner)
  private
    FStringList: TStringList;
  public
    function GetStringsList: TStringList;
    destructor Destroy; override;
  end;

  TPerson = record
  private
    FEMails: IStringListOwner;
    function GetEmails: TStringList;
  public
    Vorname: string;
    Nachname: string;
    Anschrift: string;
    property EMails: TStringList read GetEmails;
  end;

implementation

function TStringListOwner.GetStringsList: TStringList;
begin
  if not Assigned(FStringList) then
    FStringList := TStringList.Create;

  Result := FStringList;
end;

destructor TStringListOwner.Destroy;
begin
  FStringList.Free;
  inherited;
end;

function TPerson.GetEmails: TStringList;
begin
  if not Assigned(FEMails) then
    FEMails := TStringListOwner.Create;

  Result := FEMails.GetStringsList;
end;

bummi · Verfasst: Fr 27.04.12 08:24

@Blub
schöne Lösung :zustimm:

_________________
Das Problem liegt üblicherweise zwischen den Ohren H₂♂
DRY DRY KISS

Narses · Verfasst: Fr 27.04.12 11:45

Moin!

Leute, dann kann ich auch gleich ein Objekt nehmen, dann sieht der Code auch wieder besser aus... :roll:

cu
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

bummi · Verfasst: Fr 27.04.12 12:24

@Narses

jepp, allerdings ist der Aufwand bei Setlength eines Array's of Record hier doch geringer.

_________________
Das Problem liegt üblicherweise zwischen den Ohren H₂♂
DRY DRY KISS

Narses · Verfasst: Fr 27.04.12 12:42

Moin!

Das mag alles sein, aber das ist nicht "Delphi"-Code. :nixweiss:

Wenn ich eine Sprache mit Garbage-Collector toll finde, dann sollte ich diese verwenden, in Delphi kümmert man sich gewöhnlich selbst um den Speicher. Wenn ich auf so ein Konstrukt treffen würde, nur um eine Zeile Code zu sparen, dann muss ich mich doch fragen lassen, ob ich da was nicht richtig verstanden habe. Ich würde als "Delphianer" niemals so eine Konstruktion erwarten, das gehört konzeptionell in andere Sprachen - und das rechtfertigt meiner Meinung nach durchaus die Frage nach der "Lebensberechtigung" so einer "Lösung". Der Nächste, der diesen Code in die Hand kriegt, muss erstmal suchen gehen, was das soll... :roll:

Das "geht-doch"-Prinzip war schon immer ein schlechter Ratgeber.

cu
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

bummi · Verfasst: Fr 27.04.12 14:18

@Narses
ich teile Deine Abneigung gegenüber Interfaces, allerdings sind diese seit längerem und zunehmend usus auch in der Delphiumgebung.

_________________
Das Problem liegt üblicherweise zwischen den Ohren H₂♂
DRY DRY KISS

iKilledKenny · Verfasst: Fr 27.04.12 15:19

Interfaces an sich finde ich gar nicht schlecht. Es kommt aber immer drauf an, wo und wie man sie einsetzt. Das Beispiel hier ist IMHO ein schlechtes Beispiel.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme