Hallo,

ich habe eine "Basis-Singleton"-Klasse erstellt und möchte nun erweiterte Klassen entwickeln, welche das Basis-Verhalten ebenfalls besitzen. Kann ich irgendwie die Singleton-Eigenschaft nur in der Basis-Klasse kapseln und in den abgeleiteten Klassen ausschließlich die Funktionalität implementieren?

Ich denke, dass das ohne weiteres nicht gehen wird, da ich ja nur eine Instanz der Singleton-Klasse habe und für meine abgeleiteten Klassen jeweils eine neue Instanz bräuchte. Aber evtl. hat ja jemand dafür einen Workaround gefunden?

Wenn es nicht gehen sollte, werde ich in der Basisklasse halt die Singleton-Zugriffsmethoden via abstrakter Class-Funktion vorsehen und in den Unterklassen (ca 5) implementieren...

Viele Grüße,
Dominik

Hier wurde das ganze mit Templates gelöst und die entstehenden Probleme für jede andere Implementierung angesprochen. Ich nehme an, ohne Templates ist eine wirklich sichere Implementierung nicht ohne weiteres möglich, sonst hätte Schneeweiß das wohl anders gelöst. Für das ganze Type-Safety-Zeuch müsste ja der Typ der Nachfahren bereits im Basistyp bekannt sein (hat Schneeweiß über das Template realisiert) oder man müsste die entsprechenden Methoden (zumindest das Beschaffen der Instanz) in den Nachfahren type-safe reimplementieren. Wenn man als Instanzvariable den Basistyp benutzt, kommt man mit reimplementiertem Singleton-Konstruktor weiter, aber das ist ja schön der größte Teil des Singletons. Ein sicheres, vererbbares Singleton kann ich mir ohne Template kaum vorstellen, aber vielleicht bin ich nur zu sehr an C++-Eleganz gewöhnt Jedenfalls hat der Typ hier auch keine Möglichkeit gefunden, in Delphi ein Singleton zu schreiben, das type-safe ist *und* das seine Singleton-Eigenschaften vererben kann. Seiner Einleitung entnehme ich, daß es auch niemand anders geschafft hat, oder sein Wissen für sich behalten will.
Irgendwo schwirrt aber eine kranke Möglichkeit rum, Templates in Delphi zu simulieren. Das Ding ist zwar hässlich wie die Nacht und nicht annähernd in der Nähe von etwas, das man noch grob als "Benutzerfreundlichkeit" bezeichnen könnte, aber immerhin geht's irgendwie.
Außerdem bastelt jbg an etwas, aber ich weiß nicht, wie weit er ist und ob er es dir geben will, wenn's noch nicht ganz fertig ist

Aber eine ganz andere Sache: Wie willst du bei 5 verschiedenen Singleton-Nachfahren jeweils eine Instanz ermöglichen? Du bräuchtest dafür doch 5 Variablen, die über die Lebenszeit der Anwendung zugreifbar bleiben. Gibt es auch eine Möglichkeit, in Delphi statische Klassenmember zu deklarieren? Wenn nein, müsstest du doch eh deine Unit anpassen um 5 globale Variablen zur Verfügung zu stellen, die die Instanzen beinhalten.

Genau das ist halt das Problem - Templates gibt es ja leider nicht in Delphi...

Interessanter Artikel - auch wenn mir sein Ansatz zu Singletons nicht so wirklich gut gefällt.

Oh jee... Schön ist das wirklich nicht. Wenn ich mir vorstelle, diesen Ansatz für mehr als 2 Klassen zu machen, dann habe ich ne Menge Compiler-Direktiven dadrin. Gefällt mir so gar nicht

Und ich kann mich immernoch nicht mit Templates anfreunden...

Ganz genau hier habe ich auch mein Problem gesehen. Leider kann Delphi nur Klassenfunktionen, aber keine Klassenvariablen. Damit könnte man diesen ganzen Singleton-Kram viel einfacher erledigen. Endlich mal etwas, wo ich Java besser finde

Naja - ich habe jetzt auf jeden Fall für alle Klassen eine eigene Singleton-Implementation vorgesehen. Damit habe ich dann weniger Probleme. Aber dazu hätte ich auch noch eine Frage:

Wenn ich meine Oberklasse so aussieht:
Wie kann ich dann diese Instanz-Funktion korrekt zu folgendem ableiten:
So bekomme ich eine Compilerwarnmeldung. Wenn ich die Funktion overriden möchte, erhalte ich den Fehler, dass die Typen nicht zueinander kompatibel sind. Nun möchte ich aber auch nicht nur TServiceController zurückliefern, da ich dann immer casten muss... Wie mache ich das also?

Viele Grüße,
Dominik

Mehr Compiler-Direktiven als Code?
Meine persönliche Einschätzung, auch in Bezug auf die Einleitung des Artikels, des Dingens ist, daß es eher eine Spielerei ist. Er ist Delphi-Fanatiker und hatte keinen Bock mehr, von C++lern ausgelacht zu werden, und deswegen hat er sich so einen Code zusammengeschustert. Wahrscheinlich ist er auch einer derjenigen, die immer behaupten, Delphi sei soooo cool, weil der Code viel übersichtlicher und lesbarer ist als der von C++. IMAO nicht sonderlich ernst zu nehmen, auch wenn er wohl so masochistisch ist, und sowas in Produktivcode einsetzt.

Eigentlich ganz nette Freunde, wenn man sich mit ihnen ein Weilchen beschäftigt. Ich finde sie einfach praktisch, wenn es darum geht, irgendwelche Algorithmen oder Strukturen wirklich type-safe zu implementieren. Nie wieder typecasten
Aber sicherlich Gewöhnungssache.

Puh, dann hat mich mein Gedächtnis doch nicht getrügt und ich habe doch nicht ein wichtiges Feature von Delphi verpasst

Oder C++

Entwickelst du das Projekt mit Delphi2006? Dann könnten dir zumindest die Code Templates der IDE ein wenig Copy&Paste-Arbeit ersparen (und das Code Template wäre wiederverwendbar und du müsstest es nicht irgendwo aus deinen alten Units rauskopieren, wenn du mal wieder mehrere Singletons brauchst).

Beim überschreiben von virtuellen Methoden müssen die erweiterten Signaturen der Funktionen übereinstimmen. Dazu gehört auch der Rückgabewert und der Name (ergo die gesamte Deklaration muss identisch sein).
Was mir spontan einfällt:
Auch nicht schön, aber leider das einzige, was mir einfällt. Ich habe zum Beispiel auch noch keine wirklich schicke Factory in Delphi gesehen (eine Factory für mehr als eine Klasse). Entweder die Objekte müssen sich des Patterns bewusst sein (TDerivedSingleton hat eine eigene Class Function Instance(), oder bereits der Vorfahre muss über die Nachfahren informiert sein. Über eine wirklich elegante Lösung würde ich mich auch freuen, falls jemand eine hat (gescheite Smart Pointer wären dann nur noch das i-Tüpfelchen ).

Stimmt - wäre eine Idee. Aber irgendwie bin ich mit den Code-Templates noch nicht wirklich gut klargekommen. Habe mal 10 Minuten versucht mir ein kleines Template zu basteln, aber das hat nicht sofort probiert und weiter wichtig war es mir auch nicht.

1. es ist ohne virtual bei override
2. Das ist wirklich eine gute Idee. Ich kann ja da, wo ich die Oberklasse verwende, dann mit _Instance arbeiten und da wo ich die Unterklasse auch persönlich kenne mit Instance. Das hatte ich völlig übersehen - hatte in die Richtung gedacht, aber war nicht drauf gekommen . Danke

Das geht sehr wohl. Ist zwar nicht wirklich hübsch, aber auch nicht häslich.
Da ich die Klassenregistrierung in der Delphi RTL extrem widerlich finde, habe ich
alzaimars IntegerDictionary genommen.(Beide wirklich seeehr praktische Klassen, btw)
Dort habe ich den Pointer auf die jeweilige Meta class (cast auf Integer) als Key abgelegt, der dazugehörige Wert ist die Instanz dieser Klasse.
2 TestKlassen:
Der Beweis:


edit: Nachdem ich erst tommies Zitat vergass, hatte ich auch noch den TestCode mit dem StringDictionary hier abgeschickt

Das sieht mir ja genau nach dem aus, was ich eigentlich gesucht hatte Sehr sehr geil! Danke

@Elvis: Das einzig interessante an deinem Code ist das Dictionary. Bei Zuweisungen von GetInstance() findet nach wie vor ein Typecast statt. Ich bin immer noch der Meinung, daß die klassische C++-Lösung eleganter ist

Bestreitet ja auch keiner. Wir reden hier ja auch nur über Delphi.