Singleton einmal anders
5 Beiträge
•
Seite 1 von 1
5 Beiträge
Seite 1 von 1
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
Moin,
das Standard-Singleton ist definiert durch eine öffentliche, statische Methode GET_INSTANCE( ) und einem statischen privaten Attribut SINGLETON, das die Instanz enthält. GET_INSTANCE ( ) prüft nun, ob SINGLETON leer ist (wenn nicht, wird die Instanz erzeugt) und gibt den (nun in jedem Falle gefüllten Inhalt an den Aufrufer zurück.
Was spricht dagegen:
Im CLASS-CONSTRUCTOR( ) wird SINGLETON gefüllt, dann ist sie beim Aufruf von GET_INSTANCE( ) auf keinen Fall leer. So spart man sich das Prüfen und Erzeugen in GET_INSTANCE( ). Man könnte auch SINGLETON öffentlich und schreibgeschützt deklarieren, dann kann man sich auch GET_INSTANCE( ) schenken, denn spätestens beim ersten Lesezugriff auf das Attribut wird der Klassenkomstruktor aufgerufen.
Mir fallen ein paar Gegenargumente ein, auf welche kommt ihr?
Ralf
das Standard-Singleton ist definiert durch eine öffentliche, statische Methode GET_INSTANCE( ) und einem statischen privaten Attribut SINGLETON, das die Instanz enthält. GET_INSTANCE ( ) prüft nun, ob SINGLETON leer ist (wenn nicht, wird die Instanz erzeugt) und gibt den (nun in jedem Falle gefüllten Inhalt an den Aufrufer zurück.
Was spricht dagegen:
Im CLASS-CONSTRUCTOR( ) wird SINGLETON gefüllt, dann ist sie beim Aufruf von GET_INSTANCE( ) auf keinen Fall leer. So spart man sich das Prüfen und Erzeugen in GET_INSTANCE( ). Man könnte auch SINGLETON öffentlich und schreibgeschützt deklarieren, dann kann man sich auch GET_INSTANCE( ) schenken, denn spätestens beim ersten Lesezugriff auf das Attribut wird der Klassenkomstruktor aufgerufen.
Mir fallen ein paar Gegenargumente ein, auf welche kommt ihr?
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Du kannst get_instance keine Parameter mehr mitgeben.
Ansonsten: warum nicht?
Ansonsten: warum nicht?
Beitrag
von black_adept (Top Expert / 4099 / 128 /
941
)
»
- Dann ist's kein Singleton Design-Pattern mehr und manche Leute lieben Design-patterns.
- GET_INSTANCE könnte Parameter beinhalten - dann müsste der Klassenkonstruktor für alle möglichen Parameterwertkombinationen was vorhalten und das statische Attribut wäre wahrscheinlich eine Tabelle. Und wenn die Anzahl der möglichen Parameterwerte Legion ist...
- Es könnte sein, dass beim Aufruf des CC noch keine Instanz erzeugt werden kann sondern erst später ( warum auch immer ). Da du zig mal GET_INSTANCE aufrufen kannst könnte es auch mal eine Situation geben, wo es dann halt klappt
- Es könnte sein, dass die Art des Singletons sich erst beim 1. echten Aufruf ergibt und dann fix ist
- Die Klasse verwaltet mehr als ein Singleton, aber nicht alle werden zwangsläufig verwendet
- Die Verwendung des korrekt implementierten Design-Patterns ohne Rücksicht auf Verluste ergibt politische und religiöse Vorteile
Dann ist es m.E. kein Singleton mehr.black_adept hat geschrieben: Die Klasse verwaltet mehr als ein Singleton, aber nicht alle werden zwangsläufig verwendet
Beitrag
von ralf.wenzel (Top Expert / 3935 / 200 /
281
)
»
black_adept hat geschrieben:
- Dann ist's kein Singleton Design-Pattern mehr und manche Leute lieben Design-patterns.
- GET_INSTANCE könnte Parameter beinhalten - dann müsste der Klassenkonstruktor für alle möglichen Parameterwertkombinationen was vorhalten und das statische Attribut wäre wahrscheinlich eine Tabelle. Und wenn die Anzahl der möglichen Parameterwerte Legion ist...
- Die Verwendung des korrekt implementierten Design-Patterns ohne Rücksicht auf Verluste ergibt politische und religiöse Vorteile
Auf den ersten und letzten Punkt bin ich auch gekommen — wobei ich eher praktische Vorteile sehe als religiöse. Denn wenn ich ein Pattern sehe, weiß ich gleich, wie es funktioniert, das weiß ich bei anderen Konstrukten nicht.
Ich hätte noch eines, verwandt mit deinem Mittleren: Ich kann nicht verschiedene get_instances für verschiedene Fälle vorhalten. Das ist meine Variante um nicht auf diskrete (also auf eine zählbare Grundgesamtheit beruhende) Parameter zurückzugreifen. So kann kann man den Fall abdecken, dass der Constructor diskrete Parameter erwartet (den man ja von außen nicht aufrufen kann, weil privat. So kann ich von der Klasse LCL_COLOR statt einer GET_INSTANCE( schwarz ) eine GET_INSTANCE_SCHWARZ( ) verwenden, ohne prüfen zu müssen, ob schwarz eine (zulässige) Farbe ist.
Außerdem - und das ist mein zentrales Argument - kann man eine so erzeugte Instanz nur auf Umwegen zurücksetzen, weil der Klassenkonstruktor nie wieder aufgerufen wird. Bei GET_INSTANCE muss ich nur die Instanz löschen, ohne dass der Aufrufer das wissen muss.
Das ist richtig. Das wäre ein Multiton, praktisch ein Singleton, bei dem das Attribut SINGLETON eine Tabelle ist. Hab ich auch schon verwendet, um die Instanzen verwalten zu können. Dazu muss ich wissen, welche es gibt.ewx hat geschrieben:Dann ist es m.E. kein Singleton mehr.black_adept hat geschrieben: Die Klasse verwaltet mehr als ein Singleton, aber nicht alle werden zwangsläufig verwendet
Ralf *dankt für die Diskussion und wünscht allen einen guten Rutsch
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
2393
Views
Views
Table View Spalten einmal editierbar einmal nicht
von Aggressor » 08.06.2006 08:39 • Verfasst in Web-Dynpro, BSP + BHTML
von Aggressor » 08.06.2006 08:39 • Verfasst in Web-Dynpro, BSP + BHTML
11
Antw.
Antw.
6243
Views
Views
1
Antw.
Antw.
1367
Views
Views
0
Antw.
Antw.
2201
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.