Frage zu Properties

[idefix2]

Hallo,

prinzipiell sind Propeties eine schöne Sache, um damit zusätzliche Aktionen beim Zugriff auf Klassenvariable für den Benutzer der Klasse unsichtbar und nebenbei den Code lockerer zu machen:

Delphi-Quellcode:

protected oder private
FXyz: integer;
public 
property Xyz read GetXyz write SetXyz

Da kann in GetXyz und SetXyz eine Menge passieren.
Aber wozu verwendet man die Konstruktion

Delphi-Quellcode:

protected oder private 
FXyz: integer;
public 
property Xyz read FXyz write FXyz

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?

[blackfin]

z.B. für ReadOnly-Variablen?

gibst du write nicht an, hast du eine ReadOnly-Property der internen Klassenvariable

Delphi-Quellcode:

property Xyz read FXyz

[idefix2]

Schon klar. aber wenn ich eben sowohl read als auch write angeeb und in beiden Fällen den wert nur von der und zur Variablen durchreiche, ist das ganze doch völlig sinnlos, oder?

[Luckie]

Zitat:

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?

Es gibt keinen. Außer dass ein Schemaa beibehalten wird bzw. es entspricht dem OOP Konzept. Und man spart sich etwas Arbeit, wenn man keine Getter und Setter braucht.

[mkinzler]

Wenn du statt public published nimmst schon

[blackfin]

Wenn du schon von möglichlen Vorteilen sprichst:

Generell ist dies doch auch eine gute Möglichkeit, einen Rückgabewert einer Klasse im Nachhinein zu verändern.
Nehmen wir an, du hast eine Klasse gebaut und die Property X gibt einen Integer aus und hast sie als Integer in Public deklariert.
Jetzt schreibst du einige Programme und stellst fest, dass eigentlich noch eine Umrechnung nötig ist, weil du da etwas falsch gemacht hast. So etwas kommt ja durchaus mal vor.
Anstatt dass du nun deinen Programmcode ggf. umschreiben musst, so dass er immer eine Funktion (evtl noch mit einem Parameter) aufruft, kannst du in der Klasse einfach die public-variable in eine property mit einem Getter und ggf. einem Setter umbauen und dort die Umrechnung intern vollziehen, ohne dass sich am eigentlichen Programmcode etwas ändert.
Das ist doch schon einmal ein signifikanter Vorteil, oder? :)
Delphi lässt dir halt die Möglichkeiten offen, ob du nun nur den Getter oder den Setter änderst..oder beides.
Es ist ungefähr so, als ob man sich fragt, ob nun ein Vorteil besteht, x := 2 zu schreiben oder x := 2-2+2 :)
Ok, schlechtes Beispiel, steinigt mich...ich wollte eigentlich nur ausdrücken, dass es eben mehrere Möglichkeiten gibt, das gleiche zu tun. Und das bezieht sich in einer Hochsprache auf sehr viele Dinge :)

[Luckie]

Ich ziehe meinen Beitrag zurück. Ich habe nicht genau nachgedacht.

[blackfin]

@Luckie: Wenn es darum ginge, dürfte ich wohl gar nie was schreiben :)

[idefix2]

Hmmm, :gruebel: was das published in Komponenten betrifft, ist es mir auch klar - der Komponenteneditor zeigt ja glaube ich nur Properties an, oder?

Zitat:

kannst du in der Klasse einfach die public-variable in eine property mit einem Getter und ggf. einem Setter umbauen

Ja, wenn ich einen Getter oder Setter brauche, macht das ganze natürlich Sinn. Aber das könnte ich ja bei Bedarf immer noch machen, wenn sich herausstellt dass ich es brauche. Meine Frage ist konkret: Spricht etwas dagegen, direkt eine Variable als public zu erklären, solange ich weder zum Setzen noch zum Lesen des Werts eine Methode benötige? Gibt es vielleicht Probleme bei einer abgeleiteten Klasse, wenn ich dann dort eine Methode zum Setzen oder zum Lesen dieser Variable brauche?

[pixfreak]

Zitat:

Zitat von idefix2

Ja, wenn ich einen Getter oder Setter brauche, macht das ganze natürlich Sinn. Aber das könnte ich ja bei Bedarf immer noch machen, wenn sich herausstellt dass ich es brauche. Meine Frage ist konkret: Spricht etwas dagegen, direkt eine Variable als public zu erklären, solange ich weder zum Setzen noch zum Lesen des Werts eine Methode benötige? Gibt es vielleicht Probleme bei einer abgeleiteten Klasse, wenn ich dann dort eine Methode zum Setzen oder zum Lesen dieser Variable brauche?

Hi,

das kommt drauf an, ob Du die Klasse sicher machen möchtest oder nicht. Sicher in der Hinsicht, dass Du eine Kontrolle darüber hast, was bei dem Zugriff auf die Variable passiert... Ok, wenn nur Du selbst an Deinem Programm rum baust, macht das keinen großen Unterschied, da Du selber wissen solltest, was Du da macht. Aber wehe, Dein Programm wird größer und Du übersiehst den direkten, ungesteuerten Zugriff auf eine Variable, kann das Ärger geben, vor allem, wenn mehrere am Projekt arbeiten. :wink:

Außerdem ist es ja Sinn und Zweck in der OOP den Zugriff auf Variablen, oder besser Eigenschaften nicht einfach public zu machen, sondern dies gesteuert (gekapselt) ablaufen zu lassen. Dazu ein Beispiel, was oben noch garnicht erwähnt wurde: direkter Zugriff und Getter-/Setterfunktionen mixen:

Delphi-Quellcode:

  TUnfug = class
  private
    FDummerspruch: String

  public
    procedure SetDummerspruch(Spruch: String);
    
    property Dummerspruch: String read FDummerspruch write SetDummerspruch;
  end;

So wäre zumindest möglich, im Setter zu prüfen, ob der übergebene Wert überhaupt Sinn macht... :wink:


VG Pixfreak

Edit: Vor allem wenn man eine ältere Klasse hat und diese erweitert, bin ich mit dem getrennten Zugriff immer auf der sicheren Seite und brauche nicht den ganzen Code nach eventuellen Zugriff auf public Variablen absuchen und ich kann das Interface zu jeder Zeit ändern, ohne Änderung nach außen...