Delphi XE3?

[himitsu]

Oh, hatte gedacht/gehofft, daß man mehrere Helper erstellen kann. (hab's bisher aber zufällig noch nie benutzt)

Gut, ein Problem ist die Vererbungsgeschichte, also vorrangig das Problem "Was passiert, wenn in 2 Helpern die selbe Methode (Methoden-Name) vorkommt".
Wenn man die Helper voneinander ableitet, wäre das Problem behoben.
(Nja, man hätte es doch stattdessen so implementieren können, daß erst beim Aufruf einer Helpermethode diese Abhängigkeiten geprüft worden wären und hätte dann dort eine Fehlermeldung geworfen)

[Insider2004]

Ich würde Helper überhaupt nicht nehmen. Dafür gibt es Klassen und Vererbung. Helper sollten die absolute Ausnahme bleiben. Schon wie der Name sagt, es sind Helfer. Also für Integer oder Floats z.b.. Ausserdem sind sie eigentlich nur für geschlossene Objekte gedacht, wo man den Quellcode nicht hat/kennt.

[himitsu]

Wieso nicht?

Verteilte Objekte

Man könnte zu Einer Klasse/Type mehrere Methoden-Listen erstellen, vorallem wenn man nicht immer alles braucht.

Gut, man kann weitere Klassen, über Property verschachtelt anbieden, aber da hat der Compiler es schwer (es ist unmöglich) daß der Compilier dieses wegoptimiert,
denn über das vorhandene Property, aber vorallem über das interne Feld (wo z.B. diese Objektinstanz gespeichert werden muß), ist diese Klasse immer bekannt und wird auch immer einkompiliert.

Die Andere Lösung ist eine komplett unabhängig Klasse, welche, wenn man sie nicht verwendet, natürlich nicht einkompiliert wird.
Da der Helper ebenfalls "unabhängig" ist, da die eigentliche Klasse/Typ Diesen nicht kennt, kann hier der Compiler es ebenfalls wegoptimieren.


Genauso wie alles immer vorhanden ist, welches irgendwo in den Initialization-Abschnitten initialisiert wird.
Nutzt man stattdessen den Class-Constructor, dann kann der Compilier diese Klasse weglassen, da die Initialization nicht statisch eingebunden wurde.
PS: Das ist auch einer der Gründe, warum bei der VCL alles so groß wird, im Vergleich zum NonVCL.