Man kann zusammenfassend vielleicht sagen, dass es zahlreiche Fälle gibt, wo globale Variablen keinen Schaden anrichten (Disziplin vorausgesetzt), wo man sie aber dennoch durch
OOP-Konstrukte ersetzen kann. Ob man sogar die Formularvariablen verbannt, ist vermutlich eine Glaubensfrage. Solange man (vernünftigerweise) in den Formular-Units keine Business-Logik unterbringt, ist das m.E. ohne Auswirkungen auf die Fehleranfälligkeit.
Deshalb sollte man als Ersatz für globale Variablen auch nicht unbedingt Felder im Hauptformular verwenden. Besser ist da eine separate Klasse (oder mehrere logisch aufgeteilte Klassen) mit Business-Regeln, Standardwerten usw. Diese Klasse kann man dann beim Anwendungsstart initialisieren. Damit erleichtert man sich auch die Wiederverwendung, falls man dieselben Werte in einer anderen Anwendung wieder benötigen sollte.
Mit der Begründung "ist ja nur ein kleines Tool" wäre ich vorsichtig
. Ich habe schon erlebt, dass ein 150-Zeilen-Hilfsprogramm zum Durchführen eines Datenabgleichs plötzlich innerhalb von 18 Monaten zu einer spezialisierten Data-Mining-Anwendung mit einigen Tausend Programmzeilen mutiert ist. Da ist man dann heilfroh, wenn man von Anfang an das Programm sorgfältig aufgebaut hat.
Nur hat man leider oft in der Praxis mit Alt-Quellcode zu tun, bei dem man froh ist, wenn er überhaupt irgendwie strukturiert wurde. Entweder ist da von
OOP keine Spur, oder ein Genie hat alle Felder und Methoden einer Klasse als public deklariert und somit auf fast alle Vorteile der Objektorientierung verzichtet.
Für sowas schreibe ich nach Möglichkeit eine Schnittstelle (als Klasse), welche diese Units einbindet und alle Aufrufe kapselt. Dann kann ich den Alt-Code als Black Box behandeln.
Wir erstellen vorrangig Web-Anwendungen, wo man immer davon ausgehen muß, dass von jeder Ressource mehr als eine Instanz benötigt wird. Dazu arbeiten wir zum Teil mit vertraulichen Kundendaten, die auch zu Testzwecken nicht vom Original-Server gezogen werden dürfen und die sich aufgrund ihrer Komplexität auch nicht mit vertretbarem Aufwand simulieren lassen. Da ist es erforderlich, dass ein Tel der Tests dann in der Produktiv-Umgebung vorgenommen wird. Das geht natürlich nur, wenn man vorher bei kritischen Programmteilen genau weiß, wie sie sich verhalten werden. Deshalb ist es bei uns lebenswichtig, dass der Quelltext erstens sauber lesbar ist und zweitens so strukturiert, dass man ohne Probleme
Unit-Tests durchführen kann.
Auch wenn öfters mal die Zeit nicht ausreicht, die Sourcen so zu kommentieren, wie ich es gerne hätte - meine Programme sind jedenfalls auch noch nach mehreren Jahren für alle beteiligten Kollegen nachvollziehbar
.
