Singleton einmal anders

Die Objektorientierung mit ABAP®: Vererbung, Dynamische Programmierung, GUI Controls (u.a. ALV im OO).
5 Beiträge • Seite 1 von 1
5 Beiträge Seite 1 von 1

Singleton einmal anders

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Singleton einmal anders

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
Du kannst get_instance keine Parameter mehr mitgeben.
Ansonsten: warum nicht?

Re: Singleton einmal anders

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
  • 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
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Singleton einmal anders

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
black_adept hat geschrieben: Die Klasse verwaltet mehr als ein Singleton, aber nicht alle werden zwangsläufig verwendet
Dann ist es m.E. kein Singleton mehr.

Re: Singleton einmal anders

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
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.
ewx hat geschrieben:
black_adept hat geschrieben: Die Klasse verwaltet mehr als ein Singleton, aber nicht alle werden zwangsläufig verwendet
Dann ist es m.E. kein Singleton mehr.
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.



Ralf *dankt für die Diskussion und wünscht allen einen guten Rutsch
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Seite 1 von 1

Vergleichbare Themen

1
Antw.
2163
Views
Table View Spalten einmal editierbar einmal nicht
von Aggressor » 08.06.2006 08:39 • Verfasst in Web-Dynpro, BSP + BHTML
11
Antw.
7650
Views
Singleton
von Meex » 20.02.2006 09:02 • Verfasst in ABAP Objects®
11
Antw.
5809
Views
Singleton vs. statische Klasse
von ralf.wenzel » 17.12.2013 09:26 • Verfasst in ABAP Objects®
1
Antw.
1243
Views
Eigener Modus für RFC-Call (Singleton)
von just » 10.05.2006 10:29 • Verfasst in Basis
0
Antw.
2047
Views
GETTER-Methode mal anders
von ewx » 26.01.2016 09:04 • Verfasst in Tips + Tricks & FAQs

Über diesen Beitrag


Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.