Set- und Getter-Methoden

[DeddyH]

Vom logischen Fehler (fBar nur dann erzeugen, wenn es nicht nil ist?) abgesehen bekäme man dasselbe Ergebnis, wenn Bar keine Property, sondern direkt die getBar-Funktion wäre. IMO hat die Property eher mit dem Information Hiding zu tun, den Anwender der Klasse sollte es nicht interessieren, ob hinter der Eigenschaft tatsächlich eine Funktion steckt oder nicht, es genügt, wenn er weiß, dass er sie nicht beschreiben kann.

[Sir Rufo]

Im OI werden Funktionen nicht angezeigt, dafür aber Eigenschaften ;)

[DeddyH]

Aber auch nur diejenigen im published-Abschnitt. Und ob es Sinn macht, eine ReadOnly-Property im OI anzuzeigen, muss man sich im Einzelfall überlegen.

[Sir Rufo]

Zitat:

Zitat von DeddyH (Beitrag 1259290)

Aber auch nur diejenigen im published-Abschnitt. Und ob es Sinn macht, eine ReadOnly-Property im OI anzuzeigen, muss man sich im Einzelfall überlegen.

Wenn es sich um eine Instanz handelt TLabeledEdit.EditLabel ;)

[DeddyH]

Ich sag ja nicht, dass das grundsätzlich Quatsch ist, aber es ist eben auch nicht immer sinnvoll (manche Komponenten zeigen z.B. ihre Version im OI an). Dinge wie z.B. eine Count-Eigenschaft muss man ja nicht unbedingt zur Designtime verfügbar machen.

[Jumpy]

Zitat:

Zitat von DeddyH (Beitrag 1259285)

Vom logischen Fehler (fBar nur dann erzeugen, wenn es nicht nil ist?) abgesehen bekäme man dasselbe Ergebnis, wenn Bar keine Property, sondern direkt die getBar-Funktion wäre.

:oops: Ja sorry, denkfehler. <> ist jetzt =.

Natürlich geht das auch nur mit einer Funktion ohne Property, aber wenn man denn alles mit Properties macht, wäre das ein Beispiel für eine Read-Only Property.

Aber kann mas es denn nicht auch ein bißchen anhand der tatsächlichen Begrifflichkeiten definieren? Was ist eine Funktion des Objektes, was ist eine Methode?

Beispiel:

Delphi-Quellcode:

TPerson=class
  private
    fVorname:String;
    fNachname:String;
    function getName:String;
   public
    property Vorname:String read fVorname write fVorname;
    property Nachame:String read fNachname write fNachname;
    property Name:String read getName;
end;

TPerson.getName:String;
begin
  Result:=Vorname+' '+Nachname;
end;

Imho ist Name halt auch eine Eigenschaft der Person, drum als Property umgesetzt.
Die getName Funktion public gemacht und in Name umgewandelt würde auch gehen, aber irgendwie würde mich da was stören. Ist ja schon fast eine philosophische Frage. :)

(Das Name u.U. ein schlechter Name für eine Eigenchaft ist, sei mal aussen vor gelassen).

[DeddyH]

Ich gebe Dir da völlig Recht und wollte vorhin nur aufzeigen, dass man technisch gesehen für lazy initialization nicht zwingend eine Property braucht. Ich würde das allerdings auch als Eigenschaft und somit Property ansehen und deshalb genauso schreiben.

[ThaiSon96]

Auf jeden Fall sollten wir zunächst mal unsere Klassen in Klassendiagrammen darstellen (mit UML-Editor). Dabei sollte man für die versch. Attribute Lese- und Schreibanfragen erstellen (einfach Häkchen setzen). Das Programm hat dann immer für die Methoden dann "GetAttribut1" und/oder "SetAttribut1" in das Diagramm geschrieben, weshalb ich mich gefragt habe, wozu man diese beiden überhaupt braucht. Normalerweise schreibe ich einfach irgendwelche Funktionen oder Prozeduren...ansonsten hat sich das Thema eigentlich erledigt, weil das was ihr in euren Programmcodes angebt, hatte ich noch nicht. Trotzdem Danke für die Antworten!

[himitsu]

Oder als Info-Property im OI, welches dem Entwickler irgendeinen Statuswert anzeigt.

Und im Code funktioniert auch nicht immer alles.

Delphi-Quellcode:

if Assigned(MyObj.MyProp) then

ging bisher immer, während

Delphi-Quellcode:

if Assigned(MyObj.MyFunction) then

manchmal vom Compiler abgewiesen wurde. (je nach Typ)

[bernau]

Zitat:

Zitat von DeddyH (Beitrag 1259311)

Ich würde das allerdings auch als Eigenschaft und somit Property ansehen und deshalb genauso schreiben.

Wenn ich genauer drüber nachdenke, ist dies das Argument, wann man Property (readOnly) und wann man Function verwendet.

Property verwendet man für Eigenschaften wie "Laenge", "Breite", "Geschwindigkeit" etc.

Funktionen werden für Berechnungen etc. verwendet. Somit sollte im Funktionsnamen ein Verb vorhanden sein.

Habe bisher auch für Readonly-Eigenschaften "function" verwendet. Macht aber Sinn zukünftig property zu verwenden.

(Da muss ich 20 Jahre programmieren, damit mir solche trivialen Dinge auffallen :oops: )