Unterschied bei Aufruf von Variablen in eigener Komponente

[s.h.a.r.k]

Hallo.

Nachdem ich mit eurer Hilfe meine erste (recht gut funktionierende) Komponente entwickelt habe ist mir eines noch aufgefallen, wo ich nicht wirklich etwas im Internet und in meinen schlauen Bücher gefunden habe:

Und zwar habe ich ein paar Eigenschaften im published-Deklarationsteil festgelegt und ändere diese nun in einer Procedure. Nun kann ich im Prinzip auf die Variablen, welche ich ändern will, über "normalen" Namen (z.B. FTest) darauf zugreifen, aber auch über den Variablennamen ohne das "F" (z.B. Test).
Meine Frage: Wo genau liegt dort der Unterschied? Was ist schneller? Was ist die richtige und saubere Lösung?!

Des Weiteren fällt mir gleich nochmal eine Frage ein und zwar habe ich eine paar Eigenschaften, weile Untereigenschaften habe. Diese habe sind alle vom selben Typ - Beispiel:

Code:

- s1: String;
- i1: Integer;
+ var01: TTest;
  - a: String;
  - b: Integer;
+ var03: TTest;
  - a: String;
  - b: Integer;
+ var02: TTest;
  - a: String;
  - b: Integer;

Nun habe ich eine Funktion der ich einen Index übergebe und die mir dann die passende Variable liefert, d.h. für den Index 1 liefert die Funktion mir var01, für den Index 2 var02...
Wenn ich dann das Result aus der Funktion einer Variable übergebe und in Ihr etwas ändere, werden dann die Eigenschaften in der Komponente geändert oder muss ich als Ausgabe der Funktion dann Result := @...; angeben?!

Ich hoffe ihr könnt mir so früh am Morgen weiterhelfen Vielen Dank schon mal!!!

*gähn* shark

[Sharky]

Hai s.h.a.r.k

Ich denke mal das Du FTest im private Abschnitt deiner Klasse deklariert hast.

F1 sagt zu der Sichtbarkeit

Auf ein private-Element kann nur innerhalb des Moduls (Unit oder Programm) zugegriffen werden, in dem die Klasse deklariert ist.

Innerhalb von Methoden deiner Klasse kannst Du auf die F-Variable zugreifen oder auf das Property. Das macht keinen Unterschied wenn Du keine Settermethode hast.

[s.h.a.r.k]

Die Antwort auf meine erste Frage ist nun gegeben - daraus ergibt sich allerdings noch eine zweite und zwar was meinst du unter Settermethode?! Wenn ich z.B. das hier verwende:
property Test: String read FTest write SetTest; ???

[chaosben]

<einmisch_obwohl_nicht_gefragt>

Ich denke er meint so etwas:

Delphi-Quellcode:

procedure IchBinEineSetterMethode(Value : Byte);
...
property Test : Byte read FTest write IchBinEineSetterMethode;

</einmisch_obwohl_nicht_gefragt>

[Sharky]

Hai s.h.a.r.k

wenn deine Klasse zum Beispiel so aussieht:

Delphi-Quellcode:

  myClass = class
  private
    fTest : string;
    fblubb : integer;
    procedure SetTest(aValue : string);
  protected
  public
    constructor Create;
    destructor Destroy; override;
    property Test : string read fTest write SetTest;
  published

  end;

{ myClass }

constructor myClass.Create;
begin
  inherited;
  fTest := '';
  fblubb := 0;
end;

destructor myClass.Destroy;
begin

  inherited;
end;

procedure myClass.SetTest(aValue: string);  // Setter von fTest
begin
  fTest := aValue;
  fblubb := Length(aValue);
end;

dann macht es einen Unterschied ob Du fTest direkt setzt oder es über das Property Test machst.
Im ersten Fall würde "nur" ein neuer String in fTest stehen. Im zweiten wird aber auf fblubb geändert. Und wenn Du dich darauf verlassen möchtest das in fblubb immer die Stringlänge von fTest steht musst Du mit der Settermethode arbeiten (oder auch fblobb immer im Code setzen).

[s.h.a.r.k]

HAI Sharky,

danke für deinen schnellen Antworten! Das habe ich im Allgemeinen schon verstanden, trortzdem danke! Es ging nur um das Wort "Settermethode"...

Ich benutze in meiner Komponente eigentlich keine Settermethode, sonder sag halt read FTest und write FTest.

Hatte aber nochmals eine Frage:

Zitat:

Des Weiteren fällt mir gleich nochmal eine Frage ein Wink und zwar habe ich eine paar Eigenschaften, weile Untereigenschaften habe. Diese habe sind alle vom selben Typ - Beispiel:

Code:

- s1: String;
- i1: Integer;
+ var01: TTest;
  - a: String;
  - b: Integer;
+ var03: TTest;
  - a: String;
  - b: Integer;
+ var02: TTest;
  - a: String;
  - b: Integer;

Nun habe ich eine Funktion der ich einen Index übergebe und die mir dann die passende Variable liefert, d.h. für den Index 1 liefert die Funktion mir var01, für den Index 2 var02...
Wenn ich dann das Result aus der Funktion einer Variable übergebe und in Ihr etwas ändere, werden dann die Eigenschaften in der Komponente geändert oder muss ich als Ausgabe der Funktion dann Result := @...; angeben?!

mfg shark

[chaosben]

Zitat von s.h.a.r.k:

Wenn ich dann das Result aus der Funktion einer Variable übergebe und in Ihr etwas ändere, werden dann die Eigenschaften in der Komponente geändert oder muss ich als Ausgabe der Funktion dann Result := @...; angeben?!

Es kommt drauf an, was für Datentypen du zurückgeben lässt. Hier ein Teil der Delphi-Hilfe:

Zitat:

Für die Rückgabe von Funktionsergebnissen gelten folgende Konventionen.

• Funktionsergebnisse ordinalen Typs werden, wenn möglich, in ein CPU-Register zurückgegeben. Bytes werden in AL, Words in AX und Double Words in EAX zurückgegeben.
• Die Funktionsergebnisse der Real-Typen werden im Top-of-Stack-Register des Coprozessors für Gleitkommazahlen (ST(0)) zurückgegeben. Bei Funktionsergebnissen vom Typ Currency wird der Wert von ST(0) um den Faktor 10000 skaliert. Beispielsweise wird der Currency-Wert 1,234 in ST(0) als 12340 zurückgegeben.
• Strings, dynamische Arrays, Methodenzeiger oder Varianten werden so zurückgegeben, als ob das Funktionsergebnis als zusätzlicher var-Parameter nach den übrigen Parametern deklariert worden wäre. Die aufrufende Routine übergibt also einen zusätzlichen 32-Bit-Zeiger auf eine Variable, über die das Funktionsergebnis zurückgeliefert wird.
• Int64 wird in EDX:EAX zurückgegeben.
• Zeiger, Klassen, Klassenreferenzen und Prozedurzeiger werden in EAX zurückgegeben.
• Statische Arrays, Records und Mengen werden in AL zurückgegeben, wenn der Wert ein Byte belegt, in AX, falls der Wert zwei Byte belegt, und in EAX, falls vier Byte benötigt werden. Andernfalls wird der Funktion nach den deklarierten Parametern ein zusätzlicher var-Parameter übergeben, über den die Funktion das Ergebnis zurückliefert.

Aus deinen Worten schlussfolgere ich, das du willst, das du mit den zurückgegebenen Daten die Werte des Objektes ändern willst. Imho ist es in diesem Fall sinnvoll mit Pointern ("@" usw.) zu arbeiten.
Aber: Ich glaube es geht ein wenig an den Prinzipien der Objektorientierung vorbei, wenn du mit diesem "Trick" die Werte änderst und nicht über die offiziell zur Verfügung gestellten "Setter-Methoden" gehst.

[s.h.a.r.k]

Eins im Vorab: Mit ASM kenne ich mich leider gar net aus

Zu genaueren Beschreibung: Mein Problem schaut wie folgt aus: Ich habe eine Komonente mit 15 Eigenschaften, welche jeweils vom Typ TTest sind. Diese Klasse TTest hat wiederrum ca 40 Eigenschaften. Nun habe ich eine Funktion der ich eine Zahl n (0 >= n >= 14) übergebe und dann soll die entsprechende Eigenschaft der Komponente ausgegeben werden. Also praktisch so:

Delphi-Quellcode:

var
  s: TTest;
begin
...
s := GetVar(3); // Dann bekomme ich die 4. Eigenschaft
...
end;

Nun will ich allerdings wenn ich in s etwas ändere, dass sich auch die Eigenschaften automatisch ändern, ohne aber, dass ich eine Setterprocedure verwenden muss. Daher meinte Frage: Geht das nun mit dem Pointer?!


mfg shark

[chaosben]

Aha ... *pling*

Wenn TTest eine Klasse ist, dann sollte es so funktionieren wie du es da skiziert hast, da Objekte intern als Pointer bzw. Speicheradressen übergeben werden.

[tigerman33]

Hallo,

ich versuche meist zu vermeiden, pointer von innerhalb des Objekts nach außen sichtbar zu machen. Das birgt immer das Risiko, dass damit Dinge angestellt werden, für die sie nicht gedacht waren (z.B. Speicherfreigabe). Wenn dann deine Komponente später versucht, mit dem pointer zu hantieren, oder erwartet, dass eine gewisse Bedingung erfüllt ist, kann das schwer zu lokalisierende Fehler haben. Wenn du möchtest, dass sich die Eigenschaften deiner Komponente ändern, ist es i.A. sinnvoller, auch direkt mit der Komponente zu arbeiten (da kommen dann wieder die angesprochenen Settermethoden zum Einsatz).
Ausgenommen hiervon behandel ich aber Klassen. Bei diesen lässt es sich meist nicht vermeiden, und ggf kann die Klasse ja auch ihre übergeordnete Klasse von den geschehenen Veränderungen in Kenntnis setzen.

Innerhalb der Klasse vermeide ich es außerdem (außer in Constructor, Destructor, Getter und Setter) direkt auf das Feld zuzugreifen. Denn sollte ich für eine Eigenschaft später einen Setter/Getter implementieren, dann muss ich nicht den Code durchforsten und alle direkten Feldzugriffe abändern. Dadurch dass ich die ganze Zeit nur mit der property gearbeitet habe, wird "automatisch" der richtige Code ausgeführt.

PS:
(0 >= n >= 14)
Das könnte schwierig werden...