In Klasse auf Funktion zugreifen oder auf Property?

[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

[himitsu]

Ich halte es eher mehr nach Nice-Code.
Wenn diese "Funktion" logisch zu einer Reihe anderer Property gehört, dann mach ich das als ReadOnly-Property, damit es sich in der Klassendeklaration ansehnlicher einfügt.
Im Programmablauf ist es egal, da der Compiler das Property durch die Funktion ersetzt hat.

UND bei Custom-Klassen mach ich es eben so, denn Property kann man später in der Sichtbarkeit einfach verschieben.

Zitat:

Zusätzlich noch mit class und static/inline deklarationen.

Das Zusätzlich war falsch und kann hier auch falsch sein,
wenn auf Daten der Objektinstanz zugegriffen werden soll.

class function = Methode an der Klasse (nur globale Funktion ohne Bindung an eine Instanz)
function = Methode am Objekt, inkl. Zugriff auf Felder/Methoden dieser Instanz

static = statische Funktion > ohne SELF-Variable
Hier hat man nichtmal mehr Zugriff auf den aktuellen Klassentyp, bei abgeleiteten Klassen.
> der implizite SELF-Parameter wird nicht übergeben, was den Funktionsaufruf kleiner macht
> Letztendlich ist der Aufruf genau so, wie bei einer "normalen" Funktion, welche nicht in einer Klassendefinition steckt (zuzüglich Zugriff auf z.B. Class-Vars)

[günni0]

Zitat:

> Letztendlich ist der Aufruf genau so, wie bei einer "normalen" Funktion, welche nicht in einer Klassendefinition steckt (zuzüglich Zugriff auf z.B. Class-Vars)

Richtig. Ist auch immer mein Ziel. Das mit Class usw. hat den Vorteil, dass man die Unit umbenennen kann, ohne an zig-Stellen was abändern zu müssen.
Ich persönlich benenne Units oft um. Weniger oft jedoch record- und class-Namen.

Record benutze ich, um den ganzen Clutter der Codecompletion drum herum wegzubekommen.

[Delphi.Narium]

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.

Also sowas finde ich mit Properties viel schöner als ohne:

Delphi-Quellcode:

Label.Caption := Label.Caption + '*';

// statt
var
  s : String;
begin
  s := Label.GetCaption;
  s := s + '*';
  Label.SetCaption(s);
end;

// ok, das ginge wohl auch:
Label.SetCaption(Label.GetCaption + '*');

Mir gefällt die erste Variante am Besten, da sie im Quelltext am leichtesten zu lesen ist.

Und beim Programmieren interessiert es mich nicht, ob es einen Setter und einen Getter gibt. Mir reicht es, wenn ich eine Eigenschaft einfach per Zuweisung mit 'nem Wert versehen kann, ob das intern über 'nen Getter und 'nen Setter (oder jeweils nur einen davon) abläuft, interessiert mich nicht.

Baut jemand eine Klasse, bei der es für eine Eigenschaft weder Setter noch Getter gibt, so kann ich da einen Wert zuweisen.
Baut jetzt jemand später Getter und Setter ein und ich kann nur diese nutzen, so fällt eine Änderung des Quelltextes an.

Bei der Nutzung von Eigenschaften ist das für den Programmierer transparent. Die Sichtbarkeit läßt sich bei der Vererbung leicht verändern, aber über weitere interne Änderungen muss ich mir da keinen Kopp machen. Das ist innerhalb der Klasse und sollte nach außen keine Änderungen am Quelltext erforderlich machen.

[Der schöne Günther]

Bei einer Methode mit get oder set im Namen sehe ich ob es ums Lesen oder Schreiben geht. Bei einer Property weiß ich erst dass Schreiben nicht geht wenn ich F9 gedrückt, ein paar Sekunden Däumchen gedreht habe und dann unten in der Textbox eine Fehlermeldung erscheint.

Über die Jahre gerechnet habe ich damit bestimmt schon mehrere Tage Arbeitszeit gespart

[himitsu]

Zitat von Der schöne Günther:

Bei einer Property weiß ich erst dass Schreiben nicht geht wenn ich F9 gedrückt,

CodeInsight, HelpInsight, eventuell die Dokumentation (DocuInsight) und sogar die CodeCompletation hätten dir das auch sofort verraten.