Sinn einfacher Getter und Setter

[masc-online]

Hallo zusammen,

ich bin gerade wieder über einen einfachen Getter/Setter gestolpert und frage mich (mal wieder), ob es dafür tatsächlich einen sinnvollen Einsatzzweck gibt oder ob es die letztendlich nur gibt, weil man sich darauf geeinigt hat, immer Getter und Setter zu verwenden...

• Sprich hat im nachfolgenden Beispiel das Lesen/Schreibe der Property Test1 irgendwelche Vor- oder Nachteile gegenüber Test2?
• Warum wird im Setter zu Test1 erst noch die Prüfung auf Ungleichheit vorgenommen, statt einfach direkt den Wert zuzuweisen?

Bei den Fragen geht's mir bewusst um genau diese Form, bei der keine weiteren Aktionen, Checks oder Umwandlungen definiert sind.

Code:

TTestClass = class(TObject)
private
  FTest1: String;
  FTest2: String;
  function GetTest1: String; 
  procedure SetTest1(const AValue: String);
public
  property Test1: String read GetTest1 write SetTest1;
  property Test2: String read FTest2 write FTest2;
end;


function TTestClass.GetTest1: String;
begin
  Result := FTest1;
end;

procedure TTestClass.SetTest1(const AValue: String);
begin
  if (FTest1 <> AValue) then
    FTest1 := AValue;
end;

Gruß, Marian

[mkinzler]

In diesem Fall nicht (ist höchstens langsamer). Die 2. Variante erfüllt den selben Zweck.

[Sherlock]

Ich habe mir angewöhnt immer Getter und Setter zu implementieren, weil ich dann flexibel bleibe, falls ich doch noch etwas mit der Property anstellen muss.

Sherlock

[mkinzler]

Eine Property klar. Aber es macht ja keinen Unterschied, ob man eine Property von einem direkten Lese-/Schreibvorgang auf das private Feld auf eine Funktion/Prozedur umstellt oder den Inhalt der Funktion/Prozedur ändert; beides ist eine Veränderung des Codes.

Im resultierenden Kompilat ist aber der "Direkt"-Zugriff schneller.

[dummzeuch]

Es gibt mehrere Gründe, solche Methoden zu implementieren:

1. Als Debug-Hilfe. Man kann dort Breakpoints setzen, was bei direkten Feldzugriffen schwierig ist.
2. Um direkte Feldzugriffe von außen zu verhindern:
   
   Delphi-Quellcode:

   PInteger := @SomeClass.SomeProperty;
   // oder
   ProcedureWithVarParam(SomeClass.SomeProperty);

   Die würden evtl. bei späteren Änderungen zu Compilefehlern führen, was zusätzlichen Aufwand produziert. Deshalb besser schon von Anfang an verhindern.
3. Um spätere Änderungen, die zu komplexeren Methoden führen, vorzubereiten. Dies in der Regel dann natürlich mit virtuellen Methoden.

Wenn ich länger drüber nachdenke, fallen mir bestimmt noch weitere Gründe ein...

[hoika]

Hallo,
ist fürs Debuggen (Breakpoint) besser.

Frage: "Wann und in welcher Stelle wurde Property gesetzt?"
Antwort: Breakpoint auf die Set-Methode.


PS:
dummzeuch war schneller ...

[Stevie]

Zitat von mkinzler:

Aber es macht ja keinen Unterschied, ob man eine Property von einem direkten Lese-/Schreibvorgang auf das private Feld auf eine Funktion/Prozedur umstellt oder den Inhalt der Funktion/Prozedur ändert; beides ist eine Veränderung des Codes.

Falsch. Ersteres ist ein binary breaking change der API.

[mkinzler]

Zitat:

Falsch. Ersteres ist ein binary breaking change der API.

Für den "Aufrufer" ist es aber egal, was der Compiler daraus macht. Er muss seinen Code auch nicht ändern.

Aus dem Code des "Konsumenten":

Messias.Name := 'Jesus'; wird im 1. Fall

Messias.FName := 'Jesus'; und nachh der Umstellung der Implemenierung auf Getter dann

Messias.setName ('Jesus'); Das ist natürlich eine Veränderung des Binärcodes, aber kein Verhalten der "black box".