Einfache proceduren/function sinnvoll?

[himitsu]

Jupp, statt einer Get-Methode und vielleicht auch noch einer setWert1AsReal, lässt sich ein Property bestimmt intuitiver nutzen.

Vor allem wenn man bedenkt, wo man noch alles etwas einsparen/kombinieren/vereinheitlichen kann.

Delphi-Quellcode:

type
  TTest = class
  private
    function GetWertAsReal(Index: Integer): Real;
    procedure SetWertAsReal(Index: Integer; Value: Real);
  public
    //Werte: array[1..2] of String;
    Wert1: String;
    Wert2: String;
    property Wert1AsReal: Real index 1 read GetWertAsReal write SetWertAsReal;
    property Wert2AsReal: Real index 2 read GetWertAsReal write SetWertAsReal;

    property WertAsReal[Index: Integer]: Real read GetWertAsReal write SetWertAsReal; // hier im Getter/Setter die Bereichsprüfung nicht vergessen
  end;

procedure TTest.GetWertAsReal(Index: Integer): Real;
{
begin
  Result := wandleStringZuReal(Werte[Index]);
end;
}
var
  S: String;
begin
  case Index of
    1: S := Wert1;
    2: S := Wert2;
  end;
  Result := wandleStringZuReal(S);
end;
{
begin
  case Index of
    1: Result := wandleStringZuReal(Wert1);
    2: Result := wandleStringZuReal(Wert2);
    else Result := 0; // wegen Compilerwarnung
  end;
end; 
}

[Chris30]

Guten Morgen,

erstmal vielen Dank an alle die bisher geantwortet haben.
Eine Frage zu Properties hätte ich jetzt noch.

Nutzt man diese um intuitiver arbeiten zu können?
Oder gibt es noch andere unterschiede zu Standard getter und setter Methoden wie man sie vielleicht aus Java kennt?

[dummzeuch]

Zitat von Chris30:

Eine Frage zu Properties hätte ich jetzt noch.

Nutzt man diese um intuitiver arbeiten zu können?
Oder gibt es noch andere unterschiede zu Standard getter und setter Methoden wie man sie vielleicht aus Java kennt?

Properties können noch als published deklariert werden, dann kann man per Runtime Type Information (RTTI) darauf zugreifen. Neuere Delphis können das auch für nicht-published Properties.

Aber das geht jetzt deutlch über die normale Verwendung von Properties hinaus.

Anders als bei Java kann aber eine Property auch direkt auf ein Feld verweisen oder ein Feld direkt lesen aber per Setter-Methode schreiben:

Delphi-Quellcode:

type
  TMyClass
  private
    FMyField: integer;
    procedure SetMyField(_Value: integer);
  public
    property MyField: integer read FMyField write SetMyField;
  end;

Ach ja, dann gibt es noch Array-Properties:

Delphi-Quellcode:

type
  TMyClass
  private
    function GetMyProperty(_Idx: integer): string;
    procedure SetMyProperty(_Idx: integer, const _Value: string);
  public
    property MyProperty[_Idx: integer]: string read GetMyProeprty write SetMyProperty;

Eine solche Array-Property kann auch noch als default deklariert werden, so das man beim Zugriff den Namen weglassen kann. Das wird z.B. bei TStringList verwendet, eigentlich muesste man da auf die Items-Property zugreifen, es geht aber auch so:

Delphi-Quellcode:

var
  sl: TStringList;
begin
  sl := TStringList.Create;
  sl.Add('bla');
  WriteLn(sl[0]);
  WriteLn(sl.Items[0]);

[Redeemer]

Zitat von Chris30:

Nutzt man diese um intuitiver arbeiten zu können?

Prinzipiell ja.
Button1.Width := Button1.Width + 1; ist denke ich übersichtlicher als Button1.SetWidth(Button1.GetWidth() + 1); .

Wo die Grenze zwischen Funktionen und Eigenschaften liegt, frage ich mich aber auch manchmal, vor allem wenn ich eine Nur-Lesen-Eigenschaft habe. Spätestens, wenn ich eine Funktion einer Klasse schreibe, deren Name mit Get anfängt, muss ich mich unweigerlich fragen, warum ich das keine Eigenschaft ist. Vielleicht hat da ja einer eine Regel für sich.

[himitsu]

Von der Verwendung her sieht Funktion und Readonly-Property gleich aus.
Und vom compilierten Code her macht es auch keinen Unterschied.

Anders wird es, sobald es Parameter gibt, also ob ( ) oder [ ].
Hier wird es einfacher sich zu unterscheiden, also Anhand was da für Parameter rein gehn.