Singleton, Objekte übergeben oder Statische Klasse

[combie]

für welche Alternative ich mich entscheide!

Mache dich vor der Entscheidung eben noch über das "Dependency Injection Design Pattern" kundig. Üblicher Weise wird dort noch zwischen Constructor und Setter Injection unterschieden.

[AmicaNoctis]

Aber ich sehe schon, dass die Meinungen stark auseinandergehen und es schlussendlich doch Geschmacksache ist, für welche Alternative ich mich entscheide!

Meiner Meinung nach ist es nicht nur Geschmackssache und die Gründe, die gegen Singleton sprechen, habe ich genannt. Gegen die Parameterübergabe (loose coupling) spricht meines Wissens kein einziger Fakt, weswegen das für mich die einzig in Frage kommende Variante wäre

[unset]

Gegen die Parameterübergabe (loose coupling) spricht meines Wissens kein einziger Fakt, weswegen das für mich die einzig in Frage kommende Variante wäre

Aber auch nur, wenn diese funktionalen Daten (abseits der wirklichen Arbeitsparameter) tatsächlich gebündelt werden. Nichts ist schlimmer als Methoden mit 20 Parametern. Ab einer gewissen Anzahl wird es schlicht umständlich zu bedienen.

[AmicaNoctis]

Aber auch nur, wenn diese funktionalen Daten (abseits der wirklichen Arbeitsparameter) tatsächlich gebündelt werden. Nichts ist schlimmer als Methoden mit 20 Parametern. Ab einer gewissen Anzahl wird es schlicht umständlich zu bedienen.

Das hatte ich ja bereits in meiner ersten Antwort ausführlich erwähnt.

[unset]

Das hatte ich ja bereits in meiner ersten Antwort ausführlich erwähnt.

Ich weiß, und ich habe es nur noch mal betont, da Google-Suchende ja öfter mal nur ein paar Posts lesen

[goth]

Ich hätte noch einen anderen Weg anzubieten ...

Ich hätte noch einen anderen Weg anzubieten ...

Ich verwendete Jahrelang eine Basisklasse cObject, die global Verfügbare Objekte als Referenz speicherte. Alle davon abgeleiteten Klassen erbten logischerweise auch diese Eigenschaften.

Heute variiere ich das, indem die Globalen Referenzen als __get() Properties implementiert sind.

[PHP-Desaster]

Mache dich vor der Entscheidung eben noch über das "Dependency Injection Design Pattern" kundig. Üblicher Weise wird dort noch zwischen Constructor und Setter Injection unterschieden.

OffTopic:

---

Beim Öffnen des Threads hatte ich bereits diese Antwort von combie erwartet

---

[combie]

Lange gewartet, aber wenns von den Anderen nicht kommt, einer muss ja...
komme mir manchmal wie ein Papagei vor

[schmalle]

Typische Anwendungsfälle eines Singleton auf die das nicht zutrifft sind zum Beispiel Datenbank-Verbindungen & Request/Response-Objekte. Früher oder später braucht man hier eine weitere Instanz, und schon steht man vor einem Dilemma.

Das sehe ich genau anders herum. Wer es nicht auf die reihe bekommt eine DB Klasse zu schreiben, die mit mehr als einer Verbindung klarkommt, hat etwas falsch gemacht

Ich hasse es, wenn man in Projekten mehrere Instanzen braucht. Sinnloser Speicherverbrauch. Wenn man sich dazu zwingt nur eine Instanz zu haben, werden die Klassen viel "schöner"

[unset]

Das sehe ich genau anders herum. Wer es nicht auf die reihe bekommt eine DB Klasse zu schreiben, die mit mehr als einer Verbindung klarkommt, hat etwas falsch gemacht

Ich hasse es, wenn man in Projekten mehrere Instanzen braucht. Sinnloser Speicherverbrauch. Wenn man sich dazu zwingt nur eine Instanz zu haben, werden die Klassen viel "schöner"

Eine Datenbankverbindung wird durch eine Instanz repräsentiert. Wer es anders macht, hat das Konzept von Objektorientierung nicht auf die Reihe bekommen.

[AmicaNoctis]

Wer es nicht auf die reihe bekommt eine DB Klasse zu schreiben, die mit mehr als einer Verbindung klarkommt, hat etwas falsch gemacht

Eben darum braucht man eine weitere Instanz derselben Klasse oder wie willst du mehrere DB-Verbindungen in einem Singleton verwalten?

[schmalle]

Eben darum braucht man eine weitere Instanz derselben Klasse

nein :P

oder wie willst du mehrere DB-Verbindungen in einem Singleton verwalten?

// Klassenmethode für neue Verbindung

    /**
     *
     * @access public
     * @param string $db_array_name
     * connects to database
     */
    public function connect($db_array_name)
    {
        $ar = $this->connection_data[$db_array_name];
        if(empty($ar))
        {
            scp_error::fatal('missing connection data (mysql)', 'array name: '.$db_array_name, __FILE__,__CLASS__,__FUNCTION__,__LINE__);
        }    // empty connection data
        else
        {
            $this->connected = @mysql_connect($ar['host'], $ar['user'], $ar['password']);
            if(!$this->connected)
            {
                scp_error::fatal('Connection failed (mysql)', mysql_error(),__FILE__,__CLASS__,__FUNCTION__,__LINE__);
            }    // connect failed
            else
            {
                $this->ar_connections[$db_array_name] = $this->connected;
                $this->connected_to = $db_array_name;
                $this->selectDB($ar['database']);
            }    // connect ok
        }    // connection data given
    }    // connect()

// switch Methode

    /**
     *
     * @access public
     * @param string $con_name
     */
    public function switchConnection($con_name)
    {
        if(isset($this->ar_connections[$con_name]))
        {
            $this->connected = $this->ar_connections[$con_name];
            $this->connected_to = $con_name;
        }
        else
        {
            $this->connect($con_name);
        }
    }    // switchConnection() 

Funktioniert ganz wunderbar. Wenns sein muss mit X Verbindungen.

[AmicaNoctis]

Ich sehe da absolut keinen Vorteil drin. Schon alleine wegen des zusätzlichen Codes für die Singleton-Constraints und das Verbindungsswitching.

Das ist kein OOP mehr, sorry.

[h3ll]

Ich seh da eine Gefahr:

datenbankaufruf($sql);
funktion();
datenbankaufruf($sql); 

Was ist, wenn die Funktion dazwischen die Datenbankverbindung switched, ohne dass man es erwartet? Hier musst du immer volle Kontrolle auf die Funktionen haben, die du aufrufst. Oder du passt jedesmal innerhalb der Funktion auf, dass du den Ausgangszustand wiederherstellst. Wie man es auch macht, ich finde es so nur unnötig kompliziert.

[onemorenerd]

@Schmalle: Wenn du eine DB-Klasse baust, die sich ungefähr so benutzen lässt

$dbc = DBConn::getInstance();
$dbc->query($query);
$dbc->query($otherQuery, 'host2'); 

ist das kein Singleton. Man muss einen zusätzlichen Parameter übergeben, wenn man nicht die Standardverbindung benutzen möchte. Die Instanz verwaltet intern alles (Verbindungen, Queries, Resultsets) in Arrays.

Ähnlich verhält es sich bei dieser Variante, wobei hier h3lls Anmerkung bzgl. des Kontrollverlusts zu beachten ist:

$dbc1 = DBConn::getInstance();
$dbc1->query($query);
$dbc2 = DBConn::getInstance('host2');
$dbc2->query($otherQuery); 

Auch hierbei ist DBConn kein Singleton, sondern eine Registry von Singletons. Genau genommen weiß man gar nicht, ob man bei parametrisierten Calls von getInstance() die selben Instanzen bekommt. Man kann es zumindest nicht ausschließen und der Name "getInstance" ist ziemlich fest mit dem Singleton-Pattern verbunden, so dass ich davon ausgehen würde, immer die selbe Instanz zu bekommen, bei der durch die Parametrisierung intern nur ein Schalter umgelegt wurde.

Aber ganz gleich wie das Multiplexing intern implementiert ist, es handelt sich dann nicht mehr um Singleton sondern um Multiton.

Unsets Vorschlag sieht wahrscheinlich so aus:

Registry::set('dbc1', new DBConn());
Registry::set('dbc2', new DBConn('host2'));
$dbc1 = Registry::get('dbc1');
$dbc1->query($query);
$dbc2 = Registry::get('dbc2');
$dbc2->query($otherQuery); 

Hier stecken zwei Konventionen drin:
1. Man soll keine neuen Instanzen von DBConn erzeugen, sondern die aus der Registry nehmen.
2. Die Benamung der Instanzen in der Registry.
Die Einhaltung dieser Konvention kann man nicht erzwingen. Deshalb schmeckt mir persönlich dieser Ansatz auch nicht.

Fazit: Ich finde Schmalles Vorschlag sehr brauchbar. Aber er arbeitet eben nicht mit Singleton … Vorsicht bei den Begrifflichkeiten.