|
Wenn Sie in einem ActiveX-Projekt eine öffentliche globale Klasse anlegen (Instancing-Eigenschaft der Klasse = "6 - GlobalMultiUse"), kann der Verwender der Komponente deren Methoden und Eigenschaften wie eingebaute Visual Basic-Funktionen direkt nutzen. Er braucht eine solche Klasse nicht erst ausdrücklich zu instanzieren. Diese Möglichkeit der direkten Nutzung ist vor allem für Hilfs-Funktionen zur Typ-Konvertierung von Objekten und Schnittstellen der Komponente ganz praktisch (siehe beispielsweise  "Schnittstellen 'chamäleonieren'"). Oder für Funktionen, die bei der Verwendung der Komponente immer wieder benötigt werden, ohne dass sie einer bestimmten Klasse oder einem bestimmten Objekt der Komponente sinnvoll zuzuordnen wären.
Einen kleinen Haken haben diese globalen Klassen jedoch: Innerhalb des Projekts, in dem sie angelegt sind, sind sie leider nicht global. Um deren Funktionen innerhalb des Projekts zu verwenden, müssten Sie eigentlich eine Instanz anlegen, diese gegebenenfalls einmal einer globalen Objekt-Variablen in einem Standard-Modul zuweisen, um dann immer wieder über diese Objekt-Variable auf die Funktionen zuzugreifen.
Abgesehen davon, dass Sie sich damit einige unnötige Schreibarbeit bereiten, wird auch die Performance der Komponente ein wenig gebremst - vor allem, wenn Sie diese Hilfs-Funktionen häufig bis ausgiebig insbesondere an performance-kritischen Stellen einsetzen.
Die erste Alternative wäre, die Hilfs-Funktionen zusätzlich noch einmal direkt in einem Standard-Modul anzulegen. Das Performance-Problem als auch die zusätzlich Schreibarbeit hätten sich damit erledigt. Der schwerwiegende Nachteil dieser Alternative ist allerdings, dass Sie jedes Mal beide "Standorte" einer Funktion bearbeiten müssen, wenn Sie etwas in deren Code zu ändern haben.
Ehe Sie jedoch diese Alternative vorschnell verwerfen: Drehen Sie den Spieß doch einfach um. Innerhalb des Projekts verwenden Sie bequem und performant (letzteres sowohl beim Codieren als auch zur Laufzeit Ihrer Komponente) die in einem Standard-Modul angelegten Funktionen. Und in der öffentlichen globalen Klasse leiten Sie deren Funktionsaufrufe (eigentlich sind es hier ja Methoden-Aufrufe, da es sich trotz allem um eine Klasse handelt) an die Funktionen im Standard-Modul weiter. Zwar kehren Sie damit auch den Performance-Nachteil um. Doch zum einen schieben Sie den "Schwarzen Peter der Langsamkeit" elegant dem Verwender Ihrer Komponente zu, während Sie in Ihrer Komponente mit Performance glänzen können (nein, so ganz Ernst gemeint ist dieses Argument sicher nicht - aber es hat doch 'was, oder?). Zum anderen: Zwar bleibt der Performance-Verlust absolut gesehen der gleiche - aber verhältnismäßig betrachtet fällt er in Anbetracht des ohnehin bei einem Funktions- bzw. Methoden-Aufruf einer ActiveX-Komponente gegebenen Overheads nicht mehr so sehr arg ins Gewicht, für den Anwender Ihrer Komponente.
Sie könnten natürlich auch Gerechtigkeit walten lassen und Ihre globale(n) Klasse(n) in eine separate ActiveX-DLL auslagern. Damit hätte Sie für Gleichheit bei der Performance sowohl in Ihrer Komponente als auch für den Anwender derselben gesorgt. Doch was hätten Sie davon, außer Mühe bei der Organisation der Verweise innerhalb Ihrer Komponente(n) und den hin und wieder auftretenden Ärger mit der Installation einer zusätzlichen Komponente beim Anwender?
|