In Klasse auf Funktion zugreifen oder auf Property?

[norwegen60]

Hallo zusammen,

gibt es Argumente die für oder gegen einer dieser beiden Methoden sprechen? Außer der dass die zweite Lösung mehr Zeilen Code sind.

Delphi-Quellcode:

  TTest = class 
  private
  public
    function CountIrgendwas:Integer
  end;

implementation

function TTest:CountIrgendwas:Integer;
begin
  Result := (Zähl irgend was);
end;

oder

Delphi-Quellcode:

  TTest = class
  private
    FCountIrgendwas : Integer;
    function GetCountIrgendwas:Integer;
  public
    property CountIrgendwas:Integer read GetCountIrgendwas; 
  end;

implementation

function TTest:GetCountIrgendwas:Integer;
begin
  Result := (Zähl irgend was);
end;

Danke
Gerd

[günni0]

Ich mache es immer wie in deinem ersten Beispiel. Zusätzlich noch mit class und static/inline deklarationen.

Delphi-Quellcode:

 TTest = class 
  private
  public
   class function CountIrgendwas: Integer; static;
  end;

class function TTest.CountIrgendwas: Integer;
begin
 Result := (Zähl irgend was);
end;

[norwegen60]

Und was bewirkt das zusätzliche class und static?

[Sequitar]

Zitat von norwegen60:

Und was bewirkt das zusätzliche class und static?

Klassenmethoden sind solche die auf der klasse, nicht auf deren objekte angewandt werden.
Du brauchst also zum aufruf keine instanz der klasse zu erzeugen:

Delphi-Quellcode:

Type
  TAsimpleclass = Class
  Private
    Procedure Dosomething;
  End;

  Tclasswithclassmethod = Class
  Private
    Class Procedure Dosomething;
  End;

  // Implementation normaler aufruf

Procedure TAsimpleclass.Dosomething;
  Begin
    Writeln('Helloworld');
  End;
{ Beispiel klassenmethode: }

Class Procedure Tclasswithclassmethod.Dosomething;
  Begin
    Writeln('Helloworld');
  End;

Procedure Main_simple;
  Var
    Asimpleobject: TASimpleclass;
  Begin
    Asimpleobject := TASimpleclass.Create;
    // object instance der klasse TASimpleclass
    Asimpleobject.Dosomething;
    Asimpleobject.Free;
  End;

Procedure Main_classmember;
  // var Asimpleobject:TASimpleclass; //wird nicht mehr benötigt, da wir auf der Klasse operieren
  Begin
    // Asimpleobject:=TASimpleclass.create; //object instance der klasse TASimpleclass
    Tclasswithclassmethod.Dosomething;
    // direkter aufruf über den Klassennamen und die class procedure
    // Asimpleobject.free;
  End;

Begin
  Main_simple;
  Main_classmember;

End.

Erläuterung für static members:
https://ibeblog.com/2010/08/18/delphi-static-members/

[Sequitar]

Zur allgemeinen Frage:
Properties eignen sich zum kontrollierten Zugriff auf die Daten deiner objekte. Sie können lesend, schreibend oder beides sein. Demnach kannst du bestimmen wie auf deine Daten zugegriffen werden darf, anstatt jeden Nutzer direkt mit deinen Variablen in Kontakt treten zu lassen, was mglw. ungewollte Folgen haben kann.
Ausserdem kannst du relativ einfach bei vererbten klassen die zugriffs- und sichtbarkeitsrechte ändern.

Delphi-Quellcode:

Type
  TX = Class
  Private
    Fvalue: Integer;            // feld zum speichern der daten
    Function Getvalue: Integer; // zugriffsfunktion
  Protected                     // nur für Erben sichtbar
    Property Avalue: Integer Read Getvalue;
    // Zugriffsbeschränkung auf nur lesend
  Public
    Constructor Create;
  End;

 TX2 = Class(TX)
  Private
    Procedure Setvalue(Value: Integer);
  Public
    Property Avalue Write Setvalue;
    // Sichtbarkeit geändert, jetzt 'überall' sichtbar; ausserdem darf der wert geändert werden
  End;

Damit ist jetzt nur noch Folgendes möglich:

Delphi-Quellcode:

 { TX }

Constructor TX.Create;
  Begin
    Fvalue := 42;
  End;

Function TX.Getvalue: Integer;
  Begin
    Result := Fvalue;
  End;
{ TX2 }

Procedure TX2.Setvalue(Value: Integer);
  Begin
    Fvalue := Value;
  End;

Procedure Main;
  Var
    X: Tx;
    Y: Tx2;
  Begin
    X := Tx.Create;
    // X.Avalue := 42;  //Cannot assign to a read only propery
    Writeln(X.Avalue); // writes 42
    X.Free;
    Y := Tx2.Create;
    Y.Avalue := 55;
    Writeln(Y.Avalue); // writes 55
    Y.Free;
  End;

[norwegen60]

Mir ist der Sinn von Properties schon klar. Die Frage ist:
Wenn eine Funktion z.B. die Verknüpfung mehrere Properties darstellt, und damit der Wert immer nur lesend sein kann, ob es dann einen Unterschied macht ob ich direkt auf den Getter indem ich dem schon den Variablenname gebe und so direkt auf den Getter zugreife oder über den Umweg eines zusätzlichen Werts (FCountIrgendWas)

[Der schöne Günther]

Nein, technisch ist das kein Unterschied, der Compiler macht das Gleiche draus.

Der Sinn von Properties in Delphi erschließt sich mir bis heute nicht. Sie können nichts was man mit den Gettern und Settern (die man sowieso schreiben muss) nicht auch kann. Man kann sie nicht als var oder out -Parameter übergeben (z.B. Inc(someValue) ). In der Code-Completion ist noch nicht einmal sichtbar ob ich eine Property überhaupt beschreiben darf, wenn eine Methode getXX oder setXX heißt sehe ich das sofort.


Properties sind nur noch mehr Schreibarbeit. Gewonnen hat man dadurch nichts.

[norwegen60]

Hallo Günther,

Zitat von Der schöne Günther:

Properties sind nur noch mehr Schreibarbeit. Gewonnen hat man dadurch nichts.

danke für die klare Antwort. Auch wenn du mir etwas voreingenommen scheinst . Bei Variablen die Getter und Setter haben finde ich es ganz OK wobei ich die Set/Get nur verwende wenn ich noch was zusätzliche machen will. z.B. so:

Delphi-Quellcode:

TTest = class
  private
    FChanged: Boolean;
    FNormal : String;
    FTuWas : String;

    procedure SetTuWas(Value:String);
  public
    property Normal: String read FNormal write FNormal;
    property TuWas: String read FTuWas write SetTuWas;
  end;

procedure TTest.SetTuWas(Value:String);
begin
  if FTuWas <> Value then
  begin
    FTuWas := Value;
    FChanged := true;
  end;
end;

[KodeZwerg]

Ich schließe mich dem schönen Günther an wobei ich solche Klassen meist nur verwende um Original-Units zu kürzen.
Da wird dann aus "Uses SysUtils" zum Beispiel ein "SysUtils = Class". So bleibt der Aufruf im Code meist gleich.

[freimatz]

Zitat von Der schöne Günther:

Der Sinn von Properties in Delphi erschließt sich mir bis heute nicht. ...
Properties sind nur noch mehr Schreibarbeit. Gewonnen hat man dadurch nichts.

Der Sinn ist dass man eine Eigenschaft hat. Das was sich hinter Getter und Setter verbirgt gehört zusammen. Das gehört zum Thema Clean Code.
Durch die Verwendung von Eigenschaften habe ich weniger Schreibarbeit und zwar weil ich MMX verwende. Der fasst die Eigenschaft, die Getter und Setter und auch noch das Feld sofern vorhanden zusammen. Da kann ich dann:
- Getter, Setter und Feld in der Baumansicht ausblenden, es wird dadurch übersichtlicher.
- Die ganze Eigenschaft mit den Dingern auschneiden, kopieren und/oder woanders einfügen