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 ...

[Der schöne Günther]

Jetzt noch eine Frage von mir (Dieser Kreuzzug wird niemals enden) welchen Sinn machen die Properties überhaupt, warum reichen nicht einfach die public Getter und Setter?

:duck:

[freimatz]

Das ist Off-Topic, mach doch bitte einen neuen thread auf.

[mkinzler]

Properties sind lesbarer:

Delphi-Quellcode:

 irgendeineKlasse.IrgendeineProperty :=  IrgendWas;
Irgendwas := irgendeineKlasse.IrgendeineProperty;

vs

Delphi-Quellcode:

irgendeineKlasse.setIrgendWas ( IrgendWas);
Irgendwas := irgendeineKlasse.GetIrgendWas;

[ConnorMcLeod]

Wie schon gesagt wurde:
*) Zugriffssteuerung
*) Debugging
*) verschiedenes Verhalten bei Vererbung
und mein Senf:
*) Validitätsprüfungen
*) wenn Du mit Interfaces arbeitest
;-)

[Rollo62]

Dem unten Gesagten kann ich voll zustimmen.

Bei solchen simplen Typen ist das auch mehr oder weniger Egal, aber

Delphi-Quellcode:

procedure TTestClass.SetTest3(const AValue: TMyComplexClass);
begin
  if (FTest3 <> AValue) then
    FTest3.Assign( AValue );
end;

bei komplexen Assignments kann es erheblich Performance kosten wenn man immer nur blind kopiert, statt vorher auf Änderung zu Testen.

Um mir darum nicht jedes Mal Gedanken zu machen lege ich auch meistens standardmäßig Getter/Setter an,
das ist Dank Ctrl-C und/oder dem MMX-Tool ja auch kein großes Tipp-Problem mehr.

[blawen]

Zitat:

Zitat von Rollo62 (Beitrag 1430569)

das ist Dank Ctrl-C und/oder dem MMX-Tool ja auch kein großes Tipp-Problem mehr.

Mit dem Klassen-Explorer ist dies von Hause aus machbar.

[masc-online]

Danke für die Antworten und die rege Beteiligung. :thumb:

[Stevie]

Zitat:

Zitat von mkinzler (Beitrag 1430550)

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":

Delphi-Quellcode:

Messias.Name := 'Jesus';

wird im 1. Fall

Delphi-Quellcode:

Messias.FName := 'Jesus';

und nachh der Umstellung der Implemenierung auf Getter dann

Delphi-Quellcode:

Messias.setName ('Jesus');

Das ist natürlich eine Veränderung des Binärcodes, aber kein Verhalten der "black box".

[Stevie]

Es geht aber nicht immer nur um Code Änderungen sondern auch möglicherweise um Binärkompatibilität.

[hzzm]

Get/Set scheint zunaechst unwichtig und kann auch trivial geloest werden.

Wenn Du Deine Programmstruktur allerdings feinfuehliger aufbaust und statt direkten

Delphi-Quellcode:

uses

Interfaces verwendest, die Du im idealfall dann mittels Constructor Injection oder DI-container bereitstellst, musst Du somit Getter/Setter verwenden.

Interfaces lassen diese direkten Feldvariablen nicht zu.

Zum Beispiel

Delphi-Quellcode:

IAngestellter = Interface

und

Delphi-Quellcode:

TAngestellter = class(TInterfacedObject, IAngestellter)

Deine Klasse TFirma braucht Feldvariable TAngestellter.FName, verwendet aber schlankerweise nicht uses Angestellter sondern FAngestellter: IAngestellter.
Das Interface

Delphi-Quellcode:

FAngestellter

laesst FAngestellter.Name aber nicht zu, sondern nur

Delphi-Quellcode:

function FAngestellter.GetName: String;