von Bitsqueezer » 24. Nov 2020, 10:07
Hallo,
naja, "Ersatz" gibt es schon. Du könntest einerseits die Private-Variable in eine Public verwandeln und so mit Property UND Direktzugriff arbeiten. Ebenso könntest Du eine Function schreiben, die Dir den Wert der Variablen zurückliefert und eine Sub, die einen Wert setzt. Das wäre dann "Wurschtelcode".
Das ist das, was Ulrich oben mit "Programmierstil" meinte. Eine Property sollte man immer dann verwenden, wenn man eine einheitliche Art und Weise des Zugriffs auf etwas gewährleisten will, was nach außen hin nicht sichtbar sein soll oder muß. Das muß auch nicht immer zwingend eine Private-Variable sein.
Man sollte immer daran denken, daß jedes Modul in VBA eigentlich als Objekt gehandhabt wird. Das schließt auch Standardmodule ein, die lediglich die Besonderheit haben, durch VBA automatisch mit genau einer Objektinstanz erzeugt zu werden und die man nicht mehrfach instantiieren kann.
Speziell Formular- und Reportmodule aber sind ganz herkömmliche Klassenmodule. Eine Klasse ist der Bauplan für ein Objekt. Nur mit dem Objekt kann man arbeiten. Ohne Instantiierung kann man den Code im Klassenmodul nicht aufrufen (auch wenn als Public deklariert). Darum kannst Du, ohne z.B. ein Formular zu öffnen, auch nicht einen Code davon aufrufen, denn ohne Objekt (also hier: geöffnetes Formular) kannst Du nicht auf dessen Code zugreifen.
Der Sinn der Property ist es, dem Objekt eine Eigenschaft zu verpassen, daher der Name. Die Eigenschaft soll für alle außenstehende Verwender etwas zur Verfügung stellen, was sie verwenden können. Der Autor des Klassenmoduls (hier des Formularcodes) bestimmt, was Außenstehende damit machen dürfen. Daher gibt es eben die Möglichkeit, Lese-/Schreibrechte auf eine Eigenschaft zu vergeben, sowohl beide wie auch getrennt.
Du arbeitest bereits ständig damit, ohne es wahrscheinlich zu bemerken. Wenn Du etwa die Eigenschaft "WindowHeight" eines Formulares nimmst, dann findest Du in der Hilfe "schreibgeschützter Wert". Das ist dann eine Eigenschaft, die nur eine Get-Property hat, aber kein Let-Pendant. Weil der Autor bestimmt hat, daß man WindowsHeight nur auslesen darf, um die aktuelle Fensterhöhe zu erhalten, aber sie nicht verändern darf.
Mit hoher Wahrscheinlichkeit steht hinter dieser Eigenschaft keine Private-Variable im Klassenmodul Access.Form dahinter, weil es nicht notwendig ist, den Wert im Formular zu speichern. Stattdessen wird der Wert aus dem Betriebssystem zurückgegeben, was intern in der Property-Prozedur gemacht wird. Für den Eigenschaften-Verwender ist es aber eine "Variable", die direkt zum Formular gehört. Woher der Wert kommt und wie er ermittelt wird, spielt für den Verwender keine Rolle. Wenn sich der Autor der Eigenschaft irgendwann entschließt, den Wert völlig anders zu ermitteln, kann er das machen, ohne daß der Verwender das mitbekommt. Daher die "Kapselung" über eine Property. Programmierstil eben. Saubere Schnittstellen nach außen.
Ein weiterer Punkt ist, daß man eine Property wie eine Variable verwenden kann, indem man ihr mit "=" einen Wert zuweist. Würde man dazu eine Sub verwenden, wäre der Wert stattdessen ein Parameter der Sub und es wäre nicht genau zu erkennen, was da passiert, wenn nicht der Name der Sub entsprechend gestaltet ist.
Und der nächste wichtige Punkt ist, daß eine Property im Gegensatz zu einer als Public deklarierten Variable auch eine Wertprüfung vornehmen kann. So könnte man einer Property-Prozedur hinterlegen, daß der Wertebereich der Eigenschaft nur von 1 bis 12 als Integer übergeben werden darf, während intern etwa darüber hinaus daraus ein String mit führender 0 erzeugt wird. Das geht mit einer Variablen nicht.
Durch diese Art der Kapselung kann man intern im Objektcode aber frei gestalten. Die Private-Variable, in der der Wert der Property vielleicht gespeichert wird, muß nicht zwingend wie die Property heißen, wenn man sie umbenennen will, paßt man eben den Code der Property an, fertig. Für den Verwender ändert sich nichts, er verwendet ja nur den Property-Namen.
Eine Property erlaubt also das Abgrenzen des internen vom externen Code, wodurch die Codeteile unabhängiger voneinander werden und bessere Wiederverwendbarkeit ermöglichen. Ob man sie verwendet oder nicht, ist dann eben Programmierstil. Man kann halt auch Wurschtelcode schreiben, muß sich dann aber auch nicht wundern, wenn die Anwendung immer wartungsintensiver und fehleranfälliger wird, weil man alles kreuzweise "irgendwie" miteinander verknüpft hat.
Gruß
Christian