Property -> Getter und Setter mit Parametern

[Sir Rufo]

Zitat von bernau:

@Uwe: Das ist ein Ansatz, der sehr interessant aussieht.

Das meinte ich mit den Enums ... nur so nebenbei bemerkt

[Dejan Vu]

Wenn man weniger Tipparbeit haben will, würde ich mal die Programmiersprache wechseln.

Diese Klimmzüge, um Getter und Setter über indexe anzusprechen, ist doch ziemlich unsauber und irgendwie von hinten durch die Brust ins Auge. Denn was habe ich im Getter und Setter vermutlich? Ein Case, würde ich mal annehmen. Oder halten wir die Daten etwa in einem Array?

[Uwe Raabe]

Zitat von Dejan Vu:

Denn was habe ich im Getter und Setter vermutlich? Ein Case, würde ich mal annehmen. Oder halten wir die Daten etwa in einem Array?

Ein Array oder eine StringList oder sonst eine Struktur, die über einen Index angesprochen werden kann. In diesem Fall könnte ich mir auch eine Name-Value-Liste oder ein Dictionary vorstellen. Ein case halte ich für ziemlich unwahrscheinlich - habe ich jedenfalls noch nie gesehen. Ist aber vollkommen irrelevant, denn der Getter ist ja gerade dazu da, die tatsächliche Implementierung zu kapseln.

[sx2008]

Delphi-Quellcode:

TCustomSpeicherobjekt = class(TObject)
private
   function GetEinStringWert(aIndex: string): string;
   procedure SetEinStringWert(aIndex: string; const Value: string);
public
   property EinStringWert[aIndex:string]:string read GetEinStringWert write SetEinStringWert;default;
end;

Der Property EinStringWert ist ein Array-Property.
Pro Klasse kann man genau ein Array-Property zum Default-Indexer erklären (Schlüsselwort default).

Delphi-Quellcode:

var
   x : TCustomSpeicherobjekt;
begin
   x := TCustomSpeicherobjekt.Create;
   x['Host'] := 'www.delphipraxis.net';

Das spart auch Tipparbeit.

[Dejan Vu]

Zitat von Uwe Raabe:

Ein Array oder eine StringList oder sonst eine Struktur, die über einen Index angesprochen werden kann. In diesem Fall könnte ich mir auch eine Name-Value-Liste oder ein Dictionary vorstellen.

Das hat ja dann meistens etwas mit Persistenz zu tun und -wupps- habe ich wieder Zuständigkeiten vermischt.

Und selbst wenn es nichts mit Persistenz zu tun hat, ist es unsauber, denn die Tatsache, das der Wert 'FooBar' an Stelle 3 im Array stehen soll, ist somit an mehreren Stellen definiert. Ausnahme: Das Array ist ein Ersatz für private Felder. D.h. im Getter/Setter steht nur der Zugriff auf das Array. Dann...Nun ja. Spart man keine Tipparbeit, sondern hat einen Mapper geschrieben.

Die Motivation des TE ist TIPPARBEIT SPAREN und nicht, Konstrukte für Index-Properties zu finden, die sinnvoll sind.

Zitat von Uwe Raabe:

Ein case halte ich für ziemlich unwahrscheinlich - habe ich jedenfalls noch nie gesehen. Ist aber vollkommen irrelevant, denn der Getter ist ja gerade dazu da, die tatsächliche Implementierung zu kapseln.

Wer Tipparbeit sparen will, macht leider Folgendes (z.B.):

Delphi-Quellcode:

Procedure TMyClass.SetValue (Value : TSomeType;Index : Integer);
begin
  case Index of
    0 : StringValues[0] := Value.AsString;
    1 : IntegerValues[0] := Value.AsInteger;
  ...
end;

Das Beispiel stammt aus meinem uralten Code. Kapselung dient ja nicht dazu, schlechten Code zu verbergen. Sollte es zumindest nicht.

Zitat von sx2008:

Delphi-Quellcode:

var
   x : TCustomSpeicherobjekt;
begin
   x := TCustomSpeicherobjekt.Create;
   x['Host'] := 'www.delphipraxis.net';

Das spart auch Tipparbeit.

'Host' wird ja noch an einer anderen Stelle verwendet (beim Lesen nämlich). Und wenn man sich beim 'Host' vertippt hat? Meckert der Compiler natürlich nicht und es führt zu Laufzeitfehlern, die schwer zu finden sind. Beispiel: 'Нost' vs. 'Host' (Das 'H' im ersten Host wurde von meinem russischen Kollegen getippt).

Delphi ist nun mal eine Programmiersprache, die von Tastaturherstellern gesponsort wird...

[Sherlock]

Zitat von Dejan Vu:

Delphi ist nun mal eine Programmiersprache, die von Tastaturherstellern gesponsort wird...

Ich dachte immer, das war Assembler. Aber die Zeiten ändern sich wohl.

Sherlock

[bernau]

Nochmal danke für die Beiträge. Letztendlich gibt es nicht das, was ich mir vorgestellt habe. War ja auch nur ein Gedankengang.

Wichtig ist für mich, daß die Properties bestehen bleiben. Deshalb fällt der Vorschlag von z.B. sx2008 aus.

Ausserdem muss der Code lesbar bleiben. Deshalb wäre ein Sprachfeature in der Form von

Delphi-Quellcode:

// Entweder so
property WertA:string read EinStringWert['WertA'] write EinStringWert['WertA'];
// oder so
property WertB:string read GetEinStringWert('WertB') write SetEinStringWert('WertB');

eine tolle Sache. Damit wäre Tipparbeit erheblich reduziert und der Code ist besonders gut lesbar.


Der Vorschlag von "Uwe Raabe" wäre der besste. Allerdings auch nur, wenn keine Sonderzeichen benötigt werden. Folgendes wäre damit nicht möglich.

property WertA:string read EinStringWert['Wert-A-MitSonderzeichen'] write EinStringWert['Wert-A-MitSonderzeichen'];