AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Frage zu Properties

Ein Thema von idefix2 · begonnen am 13. Mai 2010 · letzter Beitrag vom 15. Mai 2010
Antwort Antwort
Seite 1 von 2  1 2      
idefix2

Registriert seit: 17. Mär 2010
Ort: Wien
1.027 Beiträge
 
RAD-Studio 2009 Pro
 
#1

Frage zu Properties

  Alt 13. Mai 2010, 22:12
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?
  Mit Zitat antworten Zitat
blackfin
(Gast)

n/a Beiträge
 
#2

Re: Frage zu Properties

  Alt 13. Mai 2010, 22:15
z.B. für ReadOnly-Variablen?

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

property Xyz read FXyz
  Mit Zitat antworten Zitat
idefix2

Registriert seit: 17. Mär 2010
Ort: Wien
1.027 Beiträge
 
RAD-Studio 2009 Pro
 
#3

Re: Frage zu Properties

  Alt 13. Mai 2010, 22:17
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?
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#4

Re: Frage zu Properties

  Alt 13. Mai 2010, 22:17
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.
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.851 Beiträge
 
Delphi 11 Alexandria
 
#5

Re: Frage zu Properties

  Alt 13. Mai 2010, 22:19
Wenn du statt public published nimmst schon
Markus Kinzler
  Mit Zitat antworten Zitat
blackfin
(Gast)

n/a Beiträge
 
#6

Re: Frage zu Properties

  Alt 13. Mai 2010, 22:30
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
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#7

Re: Frage zu Properties

  Alt 13. Mai 2010, 22:33
Ich ziehe meinen Beitrag zurück. Ich habe nicht genau nachgedacht.
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
blackfin
(Gast)

n/a Beiträge
 
#8

Re: Frage zu Properties

  Alt 13. Mai 2010, 22:43
@Luckie: Wenn es darum ginge, dürfte ich wohl gar nie was schreiben
  Mit Zitat antworten Zitat
idefix2

Registriert seit: 17. Mär 2010
Ort: Wien
1.027 Beiträge
 
RAD-Studio 2009 Pro
 
#9

Re: Frage zu Properties

  Alt 13. Mai 2010, 23:31
Hmmm, 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?
  Mit Zitat antworten Zitat
pixfreak

Registriert seit: 6. Jul 2007
112 Beiträge
 
Delphi XE3 Professional
 
#10

Re: Frage zu Properties

  Alt 14. Mai 2010, 00:30
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.

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...


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...
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:36 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz