Frage zu Properties

[idefix2]

Zitat:

Dein Programm wird größer und Du übersiehst den direkten, ungesteuerten Zugriff auf eine Variable, kann das Ärger geben,

Genau das ist es, was ich nicht verstehe. Inwiefern kann

property xyz ... read Fxyz write Fxyz irgendwelche potentiellen Probleme vermeiden, die ich hätte, wenn ich statt dessen gleich eine Variable xyz definieren würde.


Ich habe ja schon im oberen Posting geschrieben

Zitat:

wenn ich einen Getter oder Setter brauche, macht das ganze natürlich Sinn.

Darum geht es mir bei dieser Frage nicht, sondern nur um den sehr häufigen Fall, dass ich eine public Variable habe, für die ich zur Zeit WEDER getter NOCH Setter brauche. Kein Beispiel, das bis jetzt für den Vorteil einer Property gebracht worden ist, trifft auf diesen Fall zu.

Wenn ich später draufkomme, dass ich doch eine Getter oder Setter Methode verwenden will, kann ich das doch immer noch ändern, und für ein Programm, das diese Unit verwendet, egal ob als Quelltext oder als DCU, ändert sich doch eigentlich gar nichts, wenn ich zu einem späteren Zeitpunkt eine Variablen in eine Property mit Getter und/oder Setter Methode umbaue.

[mkinzler]

Es geht hier um die nachträgliche Möglichkeit einen Getter/Setter einzuführen.
In diesem Fall ist das dann einfacher. Oder wie schon erwähnt beim Ändern des Types ( Getter sorgt dann das "alte" Property ihren Typ nicht ändern muss.
Es ist nun mal ein Konzept von OOP Implementierungsdetail zu verdecen ( Abstraktion, black Box)

[hoika]

Hallo,

Zitat:

Wenn ich später draufkomme, dass ich doch eine Getter oder Setter Methode verwenden will, kann ich das doch immer noch ändern, und für ein Programm, das diese Unit verwendet, egal ob als Quelltext oder als DCU, ändert sich doch eigentlich gar nichts, wenn ich zu einem späteren Zeitpunkt eine Variablen in eine Property mit Getter und/oder Setter Methode umbaue.

Einspruch:

Delphi-Quellcode:

procedure GetData(var theValue: Integer);
begin
  theValue:= 1;
end;


type
  TClass1 = class
    i: Integer
  end;
type
  TClass2 = class
    private
      Fi: Integer;
    public
      property i: Integer
        read Fi write Fi;
  end;

var
  Class1: TClass1;
  Class2: TClass2;
begin
  Class1:= TClass1;
  GetData(Class1.i);  // das geht

  Class2:= TClass1;
  GetData(Class2.i);  // das geht nicht

Ändere ich also später eine Variable in ein Property, kann es ein,
dass bestimmter Code nicht mehr läuft.

Und das ist kein theoretischer Fall,
habe ich auch öfter (in altem Code von mir) ...


Heiko

[uligerhardt]

Zitat von hoika:

Und das ist kein theoretischer Fall,
habe ich auch öfter (in altem Code von mir) ...

Bei mir kommt alle Jubeljahre vor, das ich gerne das hätte:

Delphi-Quellcode:

type
  TTest1 = class
  strict private
    FRect: TRect;
  public
    property Rect: TRect read FRect write FRect;
  end;

aber das:

Delphi-Quellcode:

type
  TTest2 = class
  public
    Rect: TRect;
  end;

nehmen muss, damit ich auf einzelne Felder von "Rect" zugreifen kann:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  t1: TTest1;
  t2: TTest2;
begin
  t2.Rect.Top := 0; // Geht
  t1.Rect.Top := 0; // geht nicht
end;

[HeZa]

Zitat von idefix2:

Wenn die Property die Werte in beide Richtungen nur durchreicht, kann man doch genausogut gleich die Variable selbst als Public deklarieren? Wo ist der Unterschied bzw. was ist der Vorteil?

Der Unterschied ist:

* Du kannst die Adresse der Variablen nicht ermitteln (zu mindestens nicht ohne das Layout der Klasse zu kennen).
* Du kannst ein Property nicht als Var-Parameter über geben.

Der Vorteil:

Du handelst nach weit verbreiteten Delphi-Konventionen.

* Alle internen Felder ein Klasse beginnen mit "F".
* Alle internen Felder haben die Sichtbarkeit "private".
* Wenn du dein Property doch mit Getter und Setter versiehst, muss du keine Code ändern der deine Klasse verwendet, da niemand mit der Adresse des Feldes arbeiten kann und und niemand dieses Feld als Var-Parameter übergeben kann.

Auf das verletzen von Konventionen steht keine Todesstrafe (auch wenn manche so tun). Du solltest dir aber über legen ob das verletzen der Konvention dir hier irgendeinen Vorteil bringt.

[mkinzler]

Zitat:

Auf das verletzen von Konventionen steht keine Todesstrafe (auch wenn manche so tun).

Wir weisen nur auf mögliche Gefahren hin.

[hoika]

Hallo,

Todesstrafe nicht, aber ein bissel mit dem Messer kitzeln, ist erlaubt ...


Heiko

[pixfreak]

Hi zusammen,

Zitat von idefix2:

Wenn ich später draufkomme, dass ich doch eine Getter oder Setter Methode verwenden will, kann ich das doch immer noch ändern, und für ein Programm, das diese Unit verwendet, egal ob als Quelltext oder als DCU, ändert sich doch eigentlich gar nichts, wenn ich zu einem späteren Zeitpunkt eine Variablen in eine Property mit Getter und/oder Setter Methode umbaue.

Stell Dir vor: die Variable ist immer noch public gebliegen und Du musst bei jedem neuen setzen eine bestimmte Überprüfung durch führen. Nun änderst Du Deinen Code und übersiehst an einer Stelle die nötige Änderung und die Variable wird ohne Überprüfung direkt verarbeitet. Viel Spaß beim debuggen.... (Ich spreche aus eigener Erfahrung)


VG Pixfreak

[ToFaceTeKilla]

Zitat von pixfreak:

Stell Dir vor: die Variable ist immer noch public gebliegen und Du musst bei jedem neuen setzen eine bestimmte Überprüfung durch führen. Nun änderst Du Deinen Code und übersiehst an einer Stelle die nötige Änderung und die Variable wird ohne Überprüfung direkt verarbeitet. Viel Spaß beim debuggen.... (Ich spreche aus eigener Erfahrung)

VG Pixfreak

Also ich denke mal Idefix redet hier von Änderungen alá:

Delphi-Quellcode:

public
  MyVar: Integer;

welche dann auch so benutzt wird:
MyVar:= 3; Wenn du das ganze jetzt im Nachhinein mit Getter/Setter handeln willst:

Delphi-Quellcode:

private
  FMyVar: Integer;
public
  property MyVar: Integer read FMyVar write SetMyVar;

Der Zugriff bleibt überall der selbe und du musst nicht jeden noch ersetzen.

[idefix2]

@ tofacetekilla
ja, geanu so habe ich es gemeint.

Zitat:

* Du kannst die Adresse der Variablen nicht ermitteln (zu mindestens nicht ohne das Layout der Klasse zu kennen).
* Du kannst ein Property nicht als Var-Parameter über geben.

Danke, diese feinen Unterschiede zwischen Variablen und Properties waren mir nicht bewusst, obwohl es natürlich ganz logisch ist. Deshalb habe ich ja diesen Thread gestartet (ich meine nicht, weil es logisch ist, sondern weil mir diese Unterschiede nicht bewusst waren ).

Darüber, dass man auf die einzelnen Felder einer Record oder Klassenproperty nicht direkt zugreifen kann, bin ich bisher auch noch nicht gestolpert, und es ist auf jeden Fall gut, diesen Umstand im Hinterkopf zu behalten.