OOP Umwandlung eines Testprogrammes

[Uwe Raabe]

Zitat von NoGAD:

*TFooMaker* ist doch am Ende auch wieder ein globales Konstrukt, welches in jeder Unit verfügbar ist, welche Unit2 einbindet?

Die Klasse TFooMaker kann in der Tat von anderen benutzt werden. Allerdings kann jeder seine eigene Instanz erzeugen und eigene Settings verwenden. Der Instanz und den Settings in Button1Click ist das aber egal.

Ist zwar auch nur ein konstruiertes Beispiel wie der gesamte Code, aber du könntest bei deinem Originalcode in der Methode Result2Memo einfach mal das globale Settings.Show_Errors auf False setzen. Damit änderst du (in der Realität vermutlich ungewollt) das Programmverhalten. Mit der Klassenlösung ist sowas gar nicht erst möglich.

[NoGAD]

Zitat von Uwe Raabe:

Allerdings kann jeder seine eigene Instanz erzeugen und eigene Settings verwenden. Der Instanz und den Settings in Button1Click ist das aber egal.

Und warum muss es eine eigene Klasse sein?

Würde es nicht ausreichen, wenn ich den Record deklariere, um diesen dann als Variable in einer anderen Unit zu nutzen?

[stahli]

Grundsätzlich sind globale Variablen nichts schlechtes.

Generell sollten alle Konstrukte möglichst dort definiert sein, wo sie gebraucht werden.
Das beugt Nebeneffekten und Fehlern vor.

Wenn man projektweit globale Eigenschaften oder Funktionen braucht, dann kann man die auch global definieren.
Man muss nur vernünftig damit umgehen und aufpassen, dass man die nicht leichtfertig falsch verwendet.

Manche Maßnahmen, globale Variablen vermeiden zu wollen, bringen letztlich nur unnötigen Aufwand.
Man kann z.B. Variablen in Klassen statt nur in Units einbetten, das würde ich aber danach entscheiden, ob es dadurch tatsächlich übersichtlicher wird oder andere Vorteile (wie z.B. Klassenkonstruktoren o.ä.) mit sich bringt.

Also: Globale Variablen (nur) ersetzen, wenn es Sinn macht.