Singleton mit Vererbung -> Ctor Problem

[Alex04]

Hallo Zusammen;
ich bin gerade dabei den persistence-layer für mein Projekt zu schreiben.
Dabei ist mir aufgefallen, dass dies nicht so einfach ist wie in Java beispielsweise.
Was ich will ist folgendes:
BSP:

require_once("DAOBase.php");
class UserDAO extends DAOBase {

    private static $sInstance;
    
    public static function getInstance() {
        if($sInstacne == null) {
            $sInstance = new UserDAO();
        }
        return $sInstance;
    }
    
    private function __construct(){
        parent::__construct();
    }
} 

DAOBase ist abstract und soll natürlich einen public ctor haben, damit man es auch diesen auch von der Kindklasse aufrufen kann!

Da gibt es aber einen Konflikt, lass ich ihn public kommt eine Fehlermeldung
Fatal error: Access level to UserDAO::__construct() must be public (as in class DAOBase) in UserDAO.php on line 3

Markiere ich ihn als private ist er nicht mehr aufrufbar!

Eigentlich würde ich die ganzen Klassen am liebsten statisch haben, das geht aber nicht weil man anscheinend in php die Member nicht direkt mit Objekten initialisieren kann.
Also so:

class DAOBase {
protected static $mConnection = mysql_connect($mServer, $mUser, $mPassword);
} 

Also, wäre top wenn jemand eine Idee hat, wie man sowas besser löst

Vlg
Alex

[dr.e.]

DAOBase ist abstract und soll natürlich einen public ctor haben, damit man es auch diesen auch von der Kindklasse aufrufen kann!

Das ist Blödsinn. Entweder du willst Singleton haben oder nicht! Falls ja, muss der Konstruktur per Pattern-Definition private sein.

Weiterhin würde ich hier mit delegates statt mit inheritance arbeiten, das ist hinsichtlich der Abhängigkeits-Definition deutlich besser. Für den Fall der Datenbank-Connection wäre auch DI eine denkbare Gangart.

[Alex04]

Hallo,
erstmal vielen Dank für die Antwort.
Das das mit dem Singleton so nicht stimmt ist klar, mir fällt nur momentan keine andere Möglichkeit ein es sauber zu machen.
Naja, m M n sollten die DAO Methoden static sein, alle!
Doch ich habe keine Idee wie ich das hinbekomme, weder mit Vererbung noch anders.
Hast du vielleicht ein kleines Beispiel für ne saubere Lösung?
Ich zumindest komm grad net drauf!

Vielen Dank
Alex

[dr.e.]

Eine Klasse, die nur static Methoden hat, ist per Definition != OOP. Ein Objekt hat immer einen Zustand und eine definierte Life-Time. Des weiteren sind DAOs IMHO schlechter Stil. Man sollte sich mehr an das Domain-Objekt- in Kombination mit dem Data-Mapper-Pattern halten. Hier modellierst du deine Domäne sauber und hast eine zentrale Datenbank-Komponente, die die entsprechenden Objekte verwalten kann.

Elegant lässt sich das mit DI lösen, bei dem die Daten-Komponente jeweils mit der relevanten DB-Connection initialisiert wird. Ob man da nun Constructor- oder Method-Injection nutzt ist (nahezu) gleichwertig. Wichtig dabei ist, dass du eine saubere API definierst.

Hast du vielleicht ein kleines Beispiel für ne saubere Lösung?

In einem Gästebuch hast du beispielsweise 3 Objekte: User, Entry und Guestbook. Diese stehen in einem definierten Verhältnis (=Beziehungen). Diese haben wir bei der ganzen DAO-Geschichte, die nichts weiter als ein Table- oder vielmehr Row-Data-Gateway ist noch garnich beachtet. Deine Anwendung hat zudem definierte Anwendungsfälle wie das Laden eines Gästebuchs mit seinen Inhalten und den Erstellern der Beiträge oder das Speichern eines neuen Eintrags im Gästebuch zusammen mit deinem Benutzer. Ferner kann es sein, dass man sich im Gästebuch auch gleich registrieren kann oder sein Profil updaten kann. Die letzten beiden sind aber zunächst als optional zu sehen.
Die ersten beiden "Aktionen" können dann sehr einfach in folgender Form abgebildet werden:

$di = /*however we get the DI container*/
$mapper = $di->getService('GBMapper');
$gb = $mapper->loadGuestbookById(1); 

Soll das Beispiel valide sein, muss natürlich der DIContainer die aktuelle Konfiguration und das Environment kennen, in dem die Anwendung läuft. Das können Sprache, Applikations-Context, Umgebung (Live, Test, Dev, ...) oder auch noch weitere Parameter sein. Innerhalb der getService() muss der DIContainer den gewünschten Service gemäß einer Konfiguration oder Reflection-API oder Glaskugeln initialisieren. Dem Service müssen später alle UMgebungs-Parameter und die abhängigen Services zur Verfügung stehen.

Soweit klar?