OOP Variablen übergeben.

[DelphiNoob1.0]

Oh Super danke, aber wie hole ich die Wert aus Unit2?

Code:

FBorder_Pattern(stylebox1.text);

?

[mkinzler]

Garnicht, du übergibst den Wert in Unit2 an das Objekt.

<Objekt>.BorderPattern := Stylebox1.Text;

[DelphiNoob1.0]

Wozu brauch ich dann die property?

[mkinzler]

Ja man könnte auf sie verzichten, ich finde aber

obj.Top := 0; obj.Left := 0; obj.Width := 100; obj.Height := 100; Besser lesbar als

obj.SetTop(0); obj.SetLeft(0); ... Bei einer property ohne Setter/Getter wird im Kompilat, dann direkt auf die privaten Felder zugegriffen.
Später kann man dies dann einfach auf Setter/Getter umstellen ohne das der kosumierende Code geändert werden muss.

obj.Top := 0; -> obj.FTop := 0; In diesem Fall wird statt der Zuweisung der setter augerufen

obj.Top := 0; -> obj.SetTop(0); Für eine propery muss auch kein privates Feld existieren oder sie kann read oder writeonly sein

Delphi-Quellcode:

type
  Klasse = class
 private
  FGebDat: TDate;
  ...
  procedure CalcAlter: Integer;
 public
  property Alter: Integer read CalcAlter;
...
end;
...
procedure <Klasse>.CalcAlter: Integer;
begin
  result := (Today-FGebdat) DIV 364; // dirty implementation 
end;

[himitsu]

Und bevor die Frage kommt: Warum nicht die Felder public machen und einfach direkt drauf zugreifen?

A: Das wäre nicht OOP.
B: So verbaut man sich die Möglichkeit den Code zu trennen und vorallem später mal Getter und/oder Setter dazischenzuschalten.
C: Man kann den Zugriff steuern und prüfen. (übergebene Werte im Setter auf einen gültigen Bereich/Wert prüfen und im Getter prüfen ob und was gelesen wird)
D: Was die Klasse intern macht ist egal und sollte nicht nach außen getragen werden. Nur die öffentliche Schnittstelle hat externe Codes zu interessieren.
X: uvm.