Login Klasse/Meinung/Verbesserungsvorschläge

[dedlfix]

Hi!

11. Das Login als solches sollte als Singleton ausgeführt werden.
    Negativ.
    Dummerweise handelt man sich dadurch einige sehr negative Eigenschaften ein, die man bei genauerer Betrachtung nicht haben will:
    a) Global State im Objekt: Eine neue Instanz des Objektes ist nicht neu, sondern exakt das alte, schon bisher verwendete Objekt - wenn es denn vorher schon mal verwendet wurde. Es hat also evtl. schon vom Initialzustand abweichende Inhalte, und insbesondere ändert die Nutzung des "anderen" Objekts auch dieses Objekt. Sowas ist schwierig zu debuggen.

Genau das ist ja die besondere Eigenschaft eines Singleton, die man haben möchte, wenn man es einsetzt. Was sind die Alternativen? Diszipliniert nur ein einziges Objekt erstellen und dies per Dependency Injection herumzureichen? Das kommt zwar der Testbarkeit der Verwender zu Gute, aber wo lagert man dann dieses eine Objekt, wenn nicht irgendwo global? Seinen globalen Status, wie geöffnete Verbindungen, oder das Liefern von eindeutigen Werten, wozu ein Zählerstand oder eine Liste der bisherigen Werte gepflegt werden muss, soll es ja auch behalten. Warum sollte man und wie kann man den globalen Status wegbekommen?

b) Sehr eingeschränkte Testbarkeit aus demselben Grund.

Aus der Hinsicht sieht das wie ein Nachteil. Testbarkeit ist eine gute Sache, aber nicht für alle Anwendungsfälle verwendbar. Mit DI bekommt man zwar die Anwender testbarer hin, aber das Singleton selbst und seinen gewollten globalen Status ... wenn die verwendeten Testmethoden dafür nicht zielführend sind, sollte man dann nicht eher nach geeigneteren Testverfahren suchen?

c) Singletons sind in den meisten Fällen eigentlich gar nicht notwendig für das, was erreicht werden soll.

Das ist der entscheidende Punkt. Es kommt nicht darauf an, das Singleton-Pattern oder irgendein anderes Vorgehen für sich allein zu betrachten sondern seine Eigenschaften mit den Erfordernissen zu vergleichen. Erst dann kann man die Eigenschaften in positiv für das Vorhaben oder negativ für das Vorhaben einsortieren.

Kommen wir damit zu den wichtigen Fragen: Welche Aufgabe(n) genau soll das Singleton erfüllen (geht eher in Richtung Tom, weil er es vorschlug)? Welche Eigenschaften bringt es mit, die der Erfüllung der Aufgabe entgegenstehen und welche sonstigen Eigenschaften hat es, die sich in dem Fall ungünstig auswirken.

Insbesondere die globalen Eigenschaften
        ini_set('session.use_only_cookies', '1');
        ini_set('session.use_trans_sid', '0');
im Konstruktor der Klasse zu verwursten, halte ich für bedenklich.
Definitiv ja.

Begründung und Alternativen wären sehr hilfreich.

Lo!