kein Objekt erzeugt mit PDO

[Forumsgast]

Hallo, möchte (wie viele andere auch) eine Klasse bauen, die PDO verwendet. Jetzt habe ich mir überlegt, die Datenbankverbidung (mit PDO) in den Konstruktor der Klasse einzubauen. Leider bekomme ich mit
z.b. gettype($this->dbh) kein Objekt sondern NULL.
Was mache ich hier falsch?? Hier ist der Code der Klasse XSCounter:
(die Parameter für den Verbindungsaufbau stimmen!)

class XSCounter{

 private $dbh;
 private $mbytes;
 public $error = array();

   function _construct(){

  try{

  $this->dbh = new PDO("mysql:host=localhost;dbname=xsmanager","root","");
  $this->dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

   }
   catch(PDOException $e){
       echo $e->getMessage();
   }

   } 

Vielen Dank!

[Forumsgast]

__construct, zwei Unterstriche.

[Forumsgast]

Meine Kontruktoren sehen immer so aus:

public function __construct() 

Das "public" wird man wohl weglassen können, aber die zwei Unterstriche sollten es wohl schon sein.

Ansonsten würde ich persönlich sowas aber nicht in einen Konstruktor stecken, weil die Fehlerbehandlung dort schwierig ist.

[Forumsgast]

Ja, kann man weglassen.

Class properties must be defined as public, private, or protected. If declared using var, the property will be defined as public.

[…]

Note: The PHP 4 method of declaring a variable with the var keyword is still supported for compatibility reasons (as a synonym for the public keyword). In PHP 5 before 5.1.3, its usage would generate an E_STRICT warning.

[…]

Class methods may be defined as public, private, or protected. Methods declared without any explicit visibility keyword are defined as public.

- http://www.php.net/manual/en/languag...visibility.php

Ich glaube, ich finde es immer unschön, wenn Programmiersprachen so gleichberechtigte Alternativen enthalten, aber wenn es so definiert ist, kann man wenig dagegen sagen.



Ach ja, was ich eigentlich wollte:

Ansonsten würde ich persönlich sowas aber nicht in einen Konstruktor stecken, weil die Fehlerbehandlung dort schwierig ist.

Kannst du das kurz ausführen?

[Forumsgast]

Tjo, ich hatte mal gelesen, dass man im Konstruktor keine Exceptions werfen kann und ich habe es mal ganz blauäugig geglaubt
Gerade ausprobiert und es stimmt gar nicht...

Allerdings würde ich sowas persönlich trotzdem nicht im Konstruktor einbinden, weil dort dann eine Exception die komplette Objektinstanz zunichte macht und man auf gar keine Methoden mehr zugreifen kann, die vielleicht auch unabhängig einer Datenbankverbindung gebraucht werden.

[Forumsgast]

Tjo, ich hatte mal gelesen, dass man im Konstruktor keine Exceptions werfen kann und ich habe es mal ganz blauäugig geglaubt
Gerade ausprobiert und es stimmt gar nicht...

Allerdings würde ich sowas persönlich trotzdem nicht im Konstruktor einbinden, weil dort dann eine Exception die komplette Objektinstanz zunichte macht und man auf gar keine Methoden mehr zugreifen kann, die vielleicht auch unabhängig einer Datenbankverbindung gebraucht werden.

Nee das ist Unsinn, Exceptions gehören dorthin wo sie gebraucht werden.
Wenn etwas mit Übergabeparametern nicht stimmt im Konstruktor dann kann und sollte auch da eine Exception geworfen werden.
Wenn da schon ein Fehler auftritt ist es rille ob ich noch auf andere Methoden nicht zugreifen kann. Ist da was schief gelaufen ist das Objekt eben nicht brauchbar, fertig und aus.

Wenn ich auf Parameter im Konstruktor verzichten kann, weil das Objekt diese nicht zwingend brauch, dann nutze ich Setter und auch Getter wenn nötig und werfe eben da ne Exception wenn es sein muss.

Gruß der Litter

[Forumsgast]

Ich bezog mich jetzt auf dieses Beispiel mit dem Aufbau der Datenbankverbindung im Konstruktor und nicht generell darauf, ob man im Konstruktor Exceptions werfen soll oder nicht. Das kommt ja immer auf den Einzelfall an und ob man die Objektinstanz eben trotzdem weiterverwenden können soll oder nicht.
Denn um Übergabeparameter geht es hier gerade gar nicht.

[Forumsgast]

Prinzipiell unterschreibe ich das, was litter gesagt hat. Ausnahmen bestätigen die Regel.

Wenn du ein Objekt hast, das „halbfertig“ einen Sinn ergibt, würde ich erst mal annehmen, dass das Objekt für zu viel zuständig ist, also in Richtung God-Objekt geht.



Schöner ist es hier sicherlich so (Dependency Injection):

class XSCounter
{
    /**
     *
     * @var PDO
     */
    protected $dbh;

    /**
     *
     * @param PDO $dbh
     */
    public function __construct(PDO $dbh)
    {
        $this->dbh = $dbh;
    }
} 

Dann können auch andere Objekte dieselbe PDO-Instanz nutzen und der Counter muss keine Fehlerbehandlung für die Generierung der Datenbank-Verbindung implementieren (nicht seine Zuständigkeit).



PS: Wenn du trotz Dependency Injection möglichst „einfachen“ Initialisierungscode für den Nutzer der Klasse haben möchtest, liefere für diesen Zweck eine Factory mit. Zum Beispiel:

class XSCounterFactory
{
    public function create($dsn, $username, $password)
    {
        $pdo = new PDO($dsn, $username, $password);
        $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

        return new XSCounter($pdo);
    }
}

// Initialisierung

$factory = new XSCounterFactory();
$counter = $factory->create('', '', '');

// Oder ab PHP 5.4

$counter = (new XSCounterFactory())->create('', '', ''); 

Edit: Na ja, in diesem Fall mit nur einem Konstruktor-Parameter ist das vielleicht nicht notwendig.