nicht angemeldet
Bitte private. Das Singleton-Pattern lässt keine Vererbung zu, also braucht es kein protected.
Done.
Das hab ich ja schon so vorgeschlagen. Die Methode connect() sollte private sein. Alle Methoden, die einen Connect voraussetzen, rufen connect() auf. connect() baut die Verbindung auf, wenn sie noch nicht steht und ansonsten macht sie nichts. Die Zugangsdaten kann sie sich entweder von Klassenvariablen holen, die ganz am Script-Anfang, also noch vor jeglicher Verwendung von db_singleton(), gesetzt wurden, oder sie holt sie sich aus einer definierten (z.B. ini-File).
Also soll ich den Connect nicht automatisch mit dem Aufruf des Singleton machen? Weil ich mein, wenn ich das Singleton aufbaue, dann will ich auch die Verbindung haben. Logisch.
Also soll die Zuweisung in der ini stattfinden.
Sprich es steht dort z.b. drin:
db->_db_host="localhost";
? Oder wie?
Die Zugangsdatenvariablen sind ja static also müsste das doch so gehen.
Die Werte kann ich ja aufgrund des "static" übergeben bevor das Singleton geholt wird.
Du hast das Singleton-Pattern anscheinend noch nicht verstanden. Aus der Sicht der Verwender betrachtet, holt sich jeder nur über die getInstance-Methode die Instanz ab. Er kann damit sofort arbeiten, ohne sich um weitere Initialisierungen oder dergleichen zu kümmern. Aus Klassensicht sorgt getInstance für einen verwendungsfähigen Zustand der Instanz.
Alles klar, gechecked.
Die geöffnete Verbindung gehört nicht unbedingt zum verwendungsfähigen Zustand. Die kann wie schon beschrieben im Hintergrund bei tatsächlichem Bedarf eröffnet werden (lazy connect).
Halt immer wenn ich brauche, Singleton holen.
»» 3. Wie könnte die Vorabübergabe der Daten stattfinden.
»» Generell werden _alle_ Settings-Daten in einer settings.php stehen.Oder eine ini-Datei.
Macht das groß einen Unterschied? Ist das nicht latte ob das ne PHP oder ini-Datei ist?
Ich würde sie public nur mit den RUDI-Funktionen ausstatten, also Read (SELECT), Update, Delete und Insert. Wenn Bedarf in Sicht ist, kann sie immer noch erweitert werden.
Okay ich werde morgen hier mal eine Pseudo-Klasse reinschreiben.
»» 4.2 wie würdet ihr mit den beiden anderen Klassen verfahren?
Dazu müsstest du konkreter werden. Bau die Klassen mal als Rumpf auf, so dass man ihre Funktionen erkennen kann.
Folgt.. schaff ich heute nicht mehr.
»» 6. Wie betreibe ich in dem Fall am besten die Fehlerbehandlung?
Eine Klasse sollte so wenig wie möglich Fremdarbeiten erledigen. Das Schreiben ins Dateisystem erfordert beispielsweise Kenntnisse, wohin geschrieben werden soll. Vollständig behandeln kann die DB-Klasse die Fehler sowieso nicht. Sie weiß ja nicht, was die Verwender für den Fall eines Fehlers konkret vorhaben. Es ist sinnlos, das Logfile mit Meldungen vollzuschreiben, wenn explizit das Auftreten eines Fehlers vorgesehen ist. Es ist kein Logfile-Fehler, wenn ein Benutzer sich mit einer bereits vorhandenen Kennung zu registrieren versucht. Ein Insert mit dieser Kennung scheitert in dem Fall wegen Unique-Index-Verletzung. Man sagt dem Benutzer, dass er einen anderen Namen wählen muss und mehr Aufmerksamkeit benötigt diese Fehlermeldung nicht.
Ich meinte nur RUDI Fehler ;)
Wenn Fehler beim RUDI auftreten, sollten diese durch Rückgabewert oder Exception weitergemeldet werden. Reagieren und gegebenenfalls Maßnahmen treffen obliegt dem Verwender. Er muss sowieso drauf gefasst sein, dass Fehler auftreten. Einfach weiter machen wird nicht möglich sein, denn dazu fehlen ja die Daten, die man eigentlich dazu benötigte. Also muss ein alternativer Weg gegangen werden und damit hast du eine Fallunterscheidung (oder ein try-catch bei Exceptions).
Und weiter?
Das kann die Log-Klasse gern machen.
Okay also werden die RUDI Fehler an die LogKlasse weitergegeben...