![]() |
Gundsatzfrage: Zugriff auf Feld über Namen oder Property?
Hallo,
ich habe eine Klasse, die verschiedene Variablen besitzt, die ich im Private-Abschnitt deklariert habe. Für den Zugriff von außen habe ich eine entsprechende Property mit Getter- und Setter-Methoden angelegt, bzw. automatisch durch Delphi anlegen lassen. Meine Frage ist nun aber, wie man von 'innen' also von der Klasse selber aus auf diese Felder zugreift. Macht man das generell über den Namen, also bspw. fBlabla oder generell auch über die Property, oder ist das von der jeweiligen Situation abhängig? Gibt es diesbezüglich irgendein 'Regelwerk', an das man sich halten sollte? Der Grund meiner Frage ist folgender: Nehmen wir mal an, dass ich bisher in der Klasse ausschließlich über den Feldnamen direkt auf die Variable zugegriffen habe. Nun merke ich, dass ich auf dieses Feld auch von außen zugreifen muss, und erstelle mir ein entsprechendes Property. Ich überschreibe die automatisch generierte Setter-Methode, die ja per fBlabla := Value einfach direkt auf die Variable zugreift, und erweitere sie um ein paar Plausibilisierungen. Damit ich nun auch bei Zugriffen von 'innen' von diesen Plausibilisierungen profitieren kann, müsste ich sämtliche Zugriffe, die jetzt noch direkt auf den Feldnamen gehen, durch die Property ersetzen. Klar könnte man jetzt sagen, dass genau dieser Umstand doch ein eindeutiges Indiz dafür sei, dass man stets über die Property geht, und niemals direkt über den Feldnamen; auch nicht innerhalb der eigenen Klasse. Ad hoc würde ich sagen, dass nur die Initialisierung mit Defaultwerten im Constructor per Direktzugriff auf das Feld geht und alles andere über Properties; auch von 'innen'. Aber soll ich für jedes Feld eine Property anlegen, und dann darüber zugreifen, nur weil es sein könnte, dass ich irgendwann mal einen etwas umfangreicheren Getter/Setter benötige? Und wo sollte ich die Properties dann deklarieren, um den Zugriff von außen (auch in Ableitungen) erstmal zu unterbinden? Im Private-Teil? Sieht doch irgendwie seltsam aus. Auf der anderen Seite müsste ich die Sichtbarkeit dann nur noch auf protected/public erhöhen, wenn ich das Feld dann irgendwann doch mal von außen zugänglich machen möchte. Hmm, irgendwie drehe ich mich im Kreis. Wie handhabt Ihr das? |
Re: Gundsatzfrage: Zugriff auf Feld über Namen oder Property
Hallo,
"Jeder Zugriff auf eine Variable erfolgt über ein property" Punkt aus, setzen ! ;) Ich habe früher nur Variablen benutzt, bin dann aber auf den property-Geschmack gekommen. Hauptsächlich des Debuggens wegen, also um festzustellen, wann sich eine Variable ändert. Und du hast Recht, im Constructor nehme ich die private-Variable. Heiko |
Re: Gundsatzfrage: Zugriff auf Feld über Namen oder Property
Aber nicht den Fehler machen und im Setter versehentlich auf die Property zugreifen (das ist mir mal passiert).
|
Re: Gundsatzfrage: Zugriff auf Feld über Namen oder Property
Danke erstmal für Eure Antworten.
Das mit dem Debuggen hat natürlich was; so spart man sich den umständlichen Weg über Adresshaltepunkte. @Detlef: :mrgreen: Noch eine Frage: Ihr deklariert dann wirklich die Properties im Private-Abschnitt und erhöht dann entsprechend nur noch die Sichtbarkeit, wenn Ihr sie nach außen zugänglich haben möchtet? |
Re: Gundsatzfrage: Zugriff auf Feld über Namen oder Property
Wenn es sich um eine Basisklasse handelt, packt man die Properties zweckmäßigerweise in den protected-Abschnitt. Die abgeleiteten Klassen können die Sichtbarkeit dann je nach Bedarf erhöhen (die VCL macht davon selbst regen Gebrauch, schau Dir nur mal die ganzen TCustom...-Klassen an). Eine private Property macht in meinen Augen lediglich in Verbindung mit einem Setter Sinn, sonst könnte man ja gleich direkt auf das Feld zugreifen.
|
Re: Gundsatzfrage: Zugriff auf Feld über Namen oder Property
Ja, das mit der Basisklasse und Protected ist mir schon klar.
Aber da liegt ja genau das Problem. Hoika schreibt, dass jeglicher Zugriff ausschließlich über Properties gehen sollte, so wie es auch meine Vermutung war. Um den Zugriff von außen dann erstmal zu unterbinden, muss ich die Property ja als private deklarieren und kann dann ggf. die Sichtbarkeit erhöhen. Lasse ich die Property ganz weg habe ich irgendwann u.U. das Problem, alles von Feldname auf Property umzustellen, falls die Variable doch mal von außen zugänglich sein muss. Ich möchte eine generelle und möglichst flexible Lösung. Da erscheint mir das mit der Property im private-Abschnitt schon ganz nett. Die Frage ist nur, ob das sauber ist. |
Re: Gundsatzfrage: Zugriff auf Feld über Namen oder Property
Zitat:
|
Re: Gundsatzfrage: Zugriff auf Feld über Namen oder Property
Es geht erstmal um eine Klasse. Ob diese als Basisklasse dienen soll, oder nicht, ist erstmal irrelevant.
Alles kann, nichts muss :zwinker: Daher möchte ich flexibel sein. |
Re: Gundsatzfrage: Zugriff auf Feld über Namen oder Property
Gut, dann nochmal folgendes Beispiel:
Delphi-Quellcode:
Innerhalb der Implementation dieser Klasse greifst Du nur über die Property zu, richtig (außer im Getter/Setter)? Ich sehe jetzt spontan nichts, was dagegen spräche, gerade wenn der Setter noch eine Plausibilitätsprüfung enthalten sollte. Sollte sich später herausstellen, dass ein externer Zugriff sinnvoll ist, Cut&Paste auf die Property-Deklaration und Sichtbarkeit erhöhen... fertig. Ist doch ne prima Idee.
type
TMyClass = class private FFeld: integer; function GetFeld: integer; procedure SetFeld(const value: integer); property Feld: integer read GetFeld write SetFeld; protected public end; [edit] Editiert wegen fehlenden Syntax-Highlightings [/edit] |
Re: Gundsatzfrage: Zugriff auf Feld über Namen oder Property
Ihr greift auf private Felder auch innerhalb der Klasse immer via property zu? Ist das jetzt mehr "Geschmacksache" oder sinnvoll?
Wie sieht das mit Feldern aus, die Event-Methoden halten? Assigned("Getter") funktioniert ja nicht so richtig, wie man das in dem Fall erwarten würde... |
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:46 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz