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)

[MichaelT]

Für eine Property wird/wurde RTTI generiert (Hinweis auf published). Das ist mal der pragmatische Grund warum Properties sehr bliebt waren/sind neben den hier angeführten Gründen. Das hat dazu geführt, dass das Konzept ein wenig überstrapaziert wurde.

Properties sind uralt und waren tatsächlich gedacht für Datenvalidierung im Falle von Verbundstrukturen. Das Konzept der Property ist so alt, da gab es grad mal Klassen in Smalltalk in den Papers.

Du kannst die interne Repräsentation eleganter von der Außenwelt verstecken. Du weist String zu und speicherst intern bspw. eine exaktere Struktur.

Wenn du nur lesend zugreifst mache einfach eine Funktion.

[himitsu]

Zitat von MichaelT:

Das ist mal der pragmatische Grund warum Properties sehr bliebt waren/sind neben den hier angeführten Gründen.

Und man sieht es im Objektinspector.

Das kann auch für ReadOnly-Property gut sein. z.B. um dort einen internen Komponenten-Status oder die Verison anzuzeigen.


Und selbst Write-Only-Property gibt es, die manchmal ganz nett sind.

[MichaelT]

Die Properties sind ursprünglich zumeist Ganzzahlwerte oder Zeichenketten in Datenbanken (Systeminformation) in geschützten Speicherbereichen und vorzüglich Konfigurationsparameter. Weswegen die Entsprechung mit published im Kontext der IDE an sich stimmig ist.

Wenn du wirklich ein Framework dicht machen willst und gegen insbesondere unbewusste missbräuchliche Verwendung durch andere Team Mitglieder schon während der Entwicklung willst schützen musst du am Ende auf C/C++ zurückgreifen. Das ist zumeist ein Overkill. Für die gebräuchliche Verwendung ist im Delphi genug da.

Die meisten Sachen grad im Zusammenhang mit Vererbung und Delphi bspw. sind in der Praxis nicht relevant, da eine Klassenbibliothek nicht viel mehr als 4 (bis max 7 im Ausnahmefall) Vererbungstiefe sollte aufweisen. Respektive war als Delphi das Licht der Welt erblickte diese Forderung eher eine technische Notwendigkeit, aber nicht nur. die Forderung hat aber auch mit Übersichtlichkeit zu tun. Damit relativiert sich viel. Die Verantwortlichkeit ist eben sauberer abgebildet.

Jetzt werden gleich die ersten schreiben. 'Aber es darf nur einen Ort gehen an dem etwas im Programm passiert'. Das stimmt zwar, kommt aber ursprünglich aus dem systemischen Zugang zu modularen Systemen. In der echten 'OO' ist der eine Platz einfach im Kontext einer Klasse oder einem Objekt definiert welches zuständig ist. Die Hybridsprachen müssen das alles eher in der Vererbungshierarchie abbilden. Die sind ewig auf der Suche nach dem zuständigen Typen und fragen nicht einfach ein Objekt von dem sie glauben oder wissen.

So irr wie das ganze heute betrieben wird in der Objektorientierung hat auch nie jemand verlangt.

Die Java Leute haben mit den Design Patterns im Java Framework angefangen und MS hat das ganze zur Perversion getrieben. HIT ist der Standardimplementierungsmehtode, fast alles ist abgesichert bis zum Abwinken und von IDE der unterstützt. Sowie da.

Es geht heut keiner mehr her und sagt, 'Jetzt haben wir einen netten Code geschrieben und freuen uns, dass dieser sogar funktioniert'.

Die IT war schon mal gemütlicher und damals hat man sich mehr Gedanken drüber gemacht wie man sich Arbeit erspart. Diese Denke war/ist im Delphi Umfeld sehr verbreitet.

Im Ferrari einen Marathon zu fahren ist auch nicht sportlicher als gleich einen 100m Sprint laufen.

Zitat von himitsu:

Zitat von MichaelT:

Das ist mal der pragmatische Grund warum Properties sehr bliebt waren/sind neben den hier angeführten Gründen.

Und man sieht es im Objektinspector.

Das kann auch für ReadOnly-Property gut sein. z.B. um dort einen internen Komponenten-Status oder die Verison anzuzeigen.


Und selbst Write-Only-Property gibt es, die manchmal ganz nett sind.