PHP 5.2 vs PHP 5.3 parámetros por defecto

[danmichel]

Hola encontré este código en un blog y me llamo mucho la atención y me di a la tarea de implementarlo en un proyecto personal.

Para ese momento tenia instalado wampserver el cual instala como todos sabemos php5, mysql y apache. Esta versión de wampserver instalaba php 5.2.
Hasta el momento el código me funcionaba muy bien y todo corría correctamente. Luego instale el XAMPP ya que a mi entender brinda mayores prestaciones además de tener la versión de PHP 5.3 y MySQL 5.1.37.

Y entonces comenzaron mis problemas, al parecer los argumentos por defecto en PHP 5.3 se pasan de otra forma.

Código PHP:

final class Database
{
    private static $dns       = DNS;
    private static $username  = USERNAME;
    private static $password  = PASSWORD;
    private static $instance;
    private static $PDO;
 
    private function __construct() 
    {
    try {
        self::$PDO = new PDO(self::$dns, self::$username, self::$password);
        self::$PDO->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    } catch (PDOException $e) {
        echo 'Connection failed: ' . $e->getMessage();
    }
    }
    public static function getInstance()
     {
       if (!isset(self::$instance))
       {
         $c = __CLASS__;
         self::$instance = new $c;
       }
        return self::$instance;
     }
 
    public function query($statement, $PDO = null, $object = null)
    {
        return self::$PDO->query($statement, $PDO, $object);
    }
}
 
$db = Database::getInstance();
$db->query('DESCRIBE `table`');
 

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: mode must be an integer' in D:\xampp\htdocs\db\Database.php:160 Stack trace: #0 D:\xampp\htdocs\db\Database.php(160): PDO->query('DESCRIBE `table...', NULL, NULL) #1 D:\xampp\htdocs\db\Database.php(393): Database->query('DESCRIBE `table...') #2 {main} thrown in D:\xampp\htdocs\db\Database.php on line 160

No entiendo porque este mismo codigo funciona bien en PHP 5.2 y en PHP 5.3 lanza este error.

Espero que alguno de ustedes me pueda ayudar

[GatorV]

No es un error de los parámetros por defecto, si te fijas el error mismo te lo dice, que el error mode debe de ser un entero, es decir esto:

Código PHP:

self::$PDO->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
 

haz lo siguiente:

Código PHP:

var_dump(PDO::ERRMODE_EXCEPTION);
 

Ve que es lo que te sale.

Saludos.

[abimaelrc]

Además hago una observación la forma correcta de declarar static, abstract etc. es

Código PHP:

static public function getInstance()
{
 //código
}
 

Igual también las propiedades

Código PHP:

static private $PDO;
 

Otra observación WAMP tiene la version i que tiene
- Apache 2.2.11
- MySQL 5.1.36
- PHP 5.3.0

[danmichel]

abimaelrc

Gracias no sabia.

GatorV

Código PHP:

var_dump(PDO::ERRMODE_EXCEPTION);
 

me devolvió un int(3)

Creo que este no es el error.

Salu2

[abimaelrc]

¿Cuál es la línea 160?

[danmichel]

Código PHP:

return self::$PDO->query($statement, $PDO, $object);
 

Es está la línea le he quitado funcionalidades a la clase para no postearla completa.

[atrianaster]

Hola. Esta es la descripción del método query() de PDO el cual tiene varias variantes.

Descripción

Código PHP:

PDOStatement PDO::query ( string $statement )
PDOStatement PDO::query ( string $statement , int $PDO::FETCH_COLUMN , int $colno )
PDOStatement PDO::query ( string $statement , int $PDO::FETCH_CLASS , string $classname , array $ctorargs )
PDOStatement PDO::query ( string $statement , int $PDO::FETCH_INTO , object $object )
 

En tu ejemplo utilizas la primera variante, tu metodo query() de la clase Database es un wrapper al verdadero método query() de PDO y estas definiendo los demás parámetros por defecto como null.

[danmichel]

¿Entonces tendría que programar 3 métodos distintos para cada una de las variantes?

Vuelvo a la pregunta anterior. ¿Porque en PHP 5.2 me funciona bien?

[GatorV]

No, el problema es que estas pasando de forma incorrecta tu función, el problema es que si te fijas, la firma de Query necista un int en su segundo parámetro, si tu pasas null pasa un problema.

PHP5.3 es un poco más estricto que PHP5.2. Podrías hacer algo así:

Código PHP:

public function query($statement, $mode = 0, $object = null)
 

Aunque sí tendrías que hacer el chequeo de cada parámetro.

Por otro lado veo que tu clase solo es un singleton, por lo que podrías buscar otra forma de crearlo, extendiendo de la clase PDO así no tienes que sobrecargar los métodos.

Saludos.

[GatorV]

Un ejemplo:

Código PHP:

final class Database extends PDO
{
    private static $dns = DNS;
    private static $username = USERNAME;
    private static $password = PASSWORD;
    private static $PDO = null;
    
    public static function getInstance()
    {
        if (!(self::$PDO instanceof PDO)) {
            self::$PDO = new PDO(self::$dns, self::$username, self::$password);
            self::$PDO->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
        }
        return self::$PDO;
    }
}
 
$db = Database::getInstance();
$db->query('DESCRIBE `table`');
 

[danmichel]

Muchas gracias atrianaster y GatorV por su ayuda de momento probare a ver si logro dar con la solución.

[atrianaster]

Iniciado por GatorV

Por otro lado veo que tu clase solo es un singleton, por lo que podrías buscar otra forma de crearlo, extendiendo de la clase PDO así no tienes que sobrecargar los métodos.
Saludos.

Hola GatorV, muy bien pensado, seria muy buena alternativa aunque “creo que no es posible” manteniendo el ejemplo de Danmichel que su clase es un wrapper. .

Explico, esta clase Database tiene implementado el Patrón Singleton y no puede extender de PDO directamente ya que el constructor de PDO es público y uno de los requisitos del Patrón Singleton, es que el constructor debe ser privado.

Por lo que si intentas extender de esta clase te daría un:

Fatal error: Access level to Database::__construct() must be public (as in class PDO)

Aunque debe existir alguna alternativa.

[maturano]

Iniciado por atrianaster

Hola GatorV, muy bien pensado, seria muy buena alternativa aunque “creo que no es posible” [...]

Tu falta de fé me resulta molesta ...[*]

Código PHP:

final class Database extends PDO
{
 
    public function __construct()
    {
        trigger_error('Call to private ' . __CLASS__ . '::__construct() from invalid context', E_USER_ERROR);
    }
 
    static public function getInstance()
    {
        // ...
    }
}
 

Y supongo igual ayudará un "@access private" en la documentación.



---[*] Espero no tener que explicarlo

[atrianaster]

Matrano al parecer no entendiste nada. Antes de que te vuelvas a molestar, seria bueno que leyeras y analices lo que expuse anteriormente.
No me refería al ejemplo de GatorV , me refería al ejemplo que posteo DanMichel al inicio.

[maturano]

Te faltó una "u"; me leo raro.

Confieso: no leí todo el tema. Ahora lo hago y no entiendo la razón de tu reclamo. El tema si no lo he malentendido, se ha llevado así:
- danmichel coloca una clase para el manejo de la conexión a la base de datos teniendo una instancia interna de PDO.
- GatorV hace la observación que no se hace nada más allá de la implementación del patrón singleton. No es necesaria la sobre-escritura de los métodos si solo se va a ser un paso de parámetros hacia PDO. Propone, en su lugar, hacer herencia de PDO.
- Y aquí intervienes diciendo eso --la herencia-- no es posible porque un constructor público, obligado por la herencia, no cumple con el patrón singleton. Te cito (negritas de mi parte).

Iniciado por atrianaster

Explico, esta clase Database tiene implementado el Patrón Singleton y no puede extender de PDO directamente ya que el constructor de PDO es público y uno de los requisitos del Patrón Singleton, es que el constructor debe ser privado.

Correcta observación... aunque "cerrada". Te propongo ser más flexible con aquello de "el constructor deber ser privado". Lo que importa es controlar el alcance del constructor a manera de impedir se pueda obtener una instancia directa de la clase (por medio de new). Si bien ese control lo obtienes desde el lenguaje declarando el constructor como privado o protegido, igual puedes controlarlo lanzado un error de ejecución (que igual la solución te lo proporciona el lenguaje ).


Con el código que propongo obtienes el mismo comportamiento que si declararas el método como privado, cumpliendo así con "los requisitos del patrón singleton". Hasta el mensaje de error es el mismo; si camina como pato, hace como pato y se ve como pato ...

El único detalle que quedaría es hacer saber ese constructor es privado no es accesible a herramientas como un IDE y/o la generación de la documentación de la API. Para ello, mencioné, debería resolverse con la etiqueta "@access" en el "docblock" correspondiente.


Entonces, ¿en verdad no te entendí?; ¿serías tan amable de explicarme en qué?. ¿O fuiste tú quien no me entendió?; ¿me expliqué mejor ahora? ...

Y sobre la molestia, diré: triste es, una broma explicar.

[atrianaster]

Ok Matrano , es una broma.

Vamos por parte:

Iniciado por maturano

- GatorV hace la observación que no se hace nada más allá de la implementación del patrón singleton. No es necesaria la sobre-escritura de los métodos si solo se va a ser un paso de parámetros hacia PDO. Propone, en su lugar, hacer herencia de PDO.

Respeto la opinión de GatorV.

Solo 2 detalles, no seria necesario extender de PDO y que carece de constructor lo cual ya no cumpliría con el Singleton.

Código PHP:

final class Database extends PDO
      {
          private static $dns = DNS;
          private static $username = USERNAME;
          private static $password = PASSWORD;
          private static $PDO = null;
         
          public static function getInstance()
          {
              if (!(self::$PDO instanceof PDO)) {
                  self::$PDO = new PDO(self::$dns, self::$username, self::$password);
                  self::$PDO->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
              }
              return self::$PDO;
          }
      }
       
      $db = Database::getInstance();
      $db->query('DESCRIBE `table`');
 

Aunque pienso que la clase de Danmichel tiene cierto nivel de abstracción y va más allá de “una sobre-escritura de los métodos”, ya que el método query de la clase Database se abstrae del método query de PDO.

Código PHP:

final class Database
      {
          static private  $dns       = DNS;
          static private  $username  = USERNAME;
          static private  $password  = PASSWORD;
          static private  $instance;
          static private  $PDO;
 
          private function __construct()
          {
          try {
              self::$PDO = new PDO(self::$dns, self::$username, self::$password);
              self::$PDO->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
          } catch (PDOException $e) {
              echo 'Connection failed: ' . $e->getMessage();
          }
          }
          static public function getInstance()
           {
             if (!isset(self::$instance))
             {
               $c = __CLASS__;
               self::$instance = new $c;
             }
              return self::$instance;
           }
 
          public function query($statement, $PDO = null, $object = null)
          {
              return self::$PDO->query($statement, $PDO, $object);
          }
      }
      $db = Database::getInstance();
      $db->query('DESCRIBE `table`');
 

¿Que inconveniente tendríamos si quisiéramos cambiar la Capa de Abstracción de acceso a la Bases de Datos para utilizar ADODB en vez de PDO?

Supongamos que desarrollamos todo nuestro sistema invocando las propiedades y métodos que nos provee PDO directamente.

Inconvenientes

Estaríamos atados a una implementación concreta, con lo que rompemos con una premisa del Diseño Orientado a Objetos.

Tendríamos que re implementar toda nuestra lógica de negocio donde quiera que hayamos utilizado una propiedad o método pertenecientes a PDO.

- GatorV ¿Que me dices sobre abstraerse de los servicios que proveen las herramientas de abstracción de acceso a Bases de Datos, como Adodb, PDO ...?

Iniciado por maturano

Correcta observación... aunque "cerrada". Te propongo ser más flexible con aquello de "el constructor deber ser privado". Lo que importa es controlar el alcance del constructor a manera de impedir se pueda obtener una instancia directa de la clase (por medio de new). Si bien ese control lo obtienes desde el lenguaje declarando el constructor como privado o protegido, igual puedes controlarlo lanzado un error de ejecución (que igual la solución te lo proporciona el lenguaje ).

Valida tu propuesta y “buen aporte” pero de esta forma que planteas impedirías por completo la creación de instancias de la clase Database, ya que no se podría crear instancias de la misma ni dentro de la clase ni desde fuera.

Iniciado por maturano

Entonces, ¿en verdad no te entendí?; ¿serías tan amable de explicarme en qué?.

Me refería manteniendo el mismo ejemplo inicial de Danmichel “que el constructor contiene lógica”.

[maturano]

Iniciado por atrianaster

Solo 2 detalles, no seria necesario extender de PDO y que carece de constructor lo cual ya no cumpliría con el Singleton.

El detalle es que solo es código de ejemplo, solo enfocado en el problema. Así como mi código no implementa el método getInstance(). ¿Que no tiene constructor?, pues se coloca.

Iniciado por atrianaster

Aunque pienso que la clase de Danmichel tiene cierto nivel de abstracción y va más allá de “una sobre-escritura de los métodos”, ya que el método query de la clase Database se abstrae del método query de PDO.

Y lo único que hace es un paso de argumentos sin más. Aún haciendo herencia puede sobre-escribirse si hubiera más lógica no mostrada aquí.

Iniciado por atrianaster

Valida tu propuesta y “buen aporte” pero de esta forma que planteas impedirías por completo la creación de instancias de la clase Database, ya que no se podría crear instancias de la misma ni dentro de la clase ni desde fuera.

¿Aún carente de fe? ¿Qué pasa con esa creatividad compañero?. Hablando de implementaciones, capas, patrones, abstracciones ... ¿y ve esta situación imposible?.

Extendiendo PDO, implementando Singleton de la manera estándar salvo la declaración del constructor como público:

Código PHP:

class Foo extends PDO
{
    static private $instance;
 
    static private $constructIsPrivate = true;
 
    /**
     * @access private
     */
    public function __construct()
    {
        if (self::$constructIsPrivate) {
            trigger_error('Call to private ' . __CLASS__ . '::__construct() from invalid context', E_USER_ERROR);
        }
 
        echo "Ejecución normal del constructor.\n";
 
    }
 
    public static function getInstance()
    {
        if (!isset(self::$instance)) {
            self::$constructIsPrivate = false;
 
            $c = __CLASS__;
            self::$instance = new $c;
 
            self::$constructIsPrivate = true;
        }
 
        return self::$instance;
    }
}
 
// $obj = new Foo(); >> PHP Fatal error:  Call to private Foo::__construct() from invalid context
 
$obj = Foo::getInstance(); // >> Ejecución normal del constructor.
var_dump($obj); // object(Foo)
 

Iniciado por atrianaster

Me refería manteniendo el mismo ejemplo inicial de Danmichel “que el constructor contiene lógica”.

Y, como verás, puede seguir teniéndola. Sí, es posible ...

Iniciado por atrianaster

¿Que inconveniente tendríamos si quisiéramos cambiar la Capa de Abstracción de acceso a la Bases de Datos para utilizar ADODB en vez de PDO?

Supongamos que desarrollamos todo nuestro sistema invocando las propiedades y métodos que nos provee PDO directamente.

Inconvenientes

Estaríamos atados a una implementación concreta, con lo que rompemos con una premisa del Diseño Orientado a Objetos.

Tendríamos que re implementar toda nuestra lógica de negocio donde quiera que hayamos utilizado una propiedad o método pertenecientes a PDO.

- GatorV ¿Que me dices sobre abstraerse de los servicios que proveen las herramientas de abstracción de acceso a Bases de Datos, como Adodb, PDO ...?

Ajá, ajá, ajá. De acuerdo, de acuerdo, de acuerdo ... pero ¿y si nos enfocamos?. Estamos hablando de una clase en concreto, de un código concreto.

El asunto es, para el código presentado, la herencia es posible, quedando un mejor código y siendo el cambio transparente para quien utilice la clase. Estas últimas intervenciones son porque hiciste una --buena-- observación correcta (no se puede declarar el constructor como privado) y otra errada (sí se puede implementar Singleton con un constructor púbico). Lo demás es solo ruido (no tienes por qué copiar también las actitudes ).


Entonces, ¿convencido?, ¿hay más peros?

Que la fuerza esté contigo.

[atrianaster]

maturano:

Nunca afirme que no se podía. En cuanto a tu código buen aporte, veo que estuviste haciendo la tarea en casa. Estoy convencido y no hay más peros.

El código quedaría así:

Código PHP:

<?php
/**
 * Represents a connection between PHP and a database server
 *
 */
final class Database extends PDO
{
    static private  $dns = DNS;
    static private  $username = USERNAME;
    static private  $passwd = PASSWD;
    static private  $options;
    static private  $instance;
    static private  $constructIsPrivate = true;
 
    /**
     * A private constructor; prevents direct creation of object
     *
     * @access static private
     */
    public function __construct()
    {
      if (self::$constructIsPrivate) {
         trigger_error('Call to private ' . __CLASS__ . '::__construct() from invalid context', E_USER_ERROR);
      }
      try {
           parent::__construct(self::$dns, self::$username, self::$passwd/*, self::$options*/);
           $this->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
      } catch (PDOException $e) {
           echo 'Connection failed: ' . $e->getMessage();
      }
    }
 
    /**
     * Create a instance of Database class with The singleton method
     *
     * @access static public
     * @return Database object
     */
     static public function getInstance()
     {
       if (!isset(self::$instance))
       {
         self::$constructIsPrivate = false;
         $c = __CLASS__;
         self::$instance = new $c;
         self::$constructIsPrivate = true;
       }
        return self::$instance;
     }
 
    /**
     * Executes an SQL statement, returning a result set as a PDOStatement object
     *
     * @access public
     * @param  string $statement
     * @param  $PDO
     * @param  object $object
     * @return PDOStatement
     */
     public function query($statement, $PDO, $object)
     {
        return parent::query($statement, $PDO, $object);
     }
 
 
    /**
     * Prevent users to clone the instance
     *
     * @access public
     * @return string trigger_error
     */
    public function __clone()
    {
        trigger_error('Clone is not allowed.', E_USER_ERROR);
    }
}
?>
 

[danmichel]

Se aprende mucha POO en Foros del Web, gracias todos, veo que tienen mucha experiencia.

Mi última duda, como podría implementar el método query, que en dependencia de la variante que use invoque al método correspondiente. Pero lo que deseo es centralizarlo todo en el mismo método.

Estas son las variantes disponibles de dicho método:

Código PHP:

PDOStatement PDO::query ( string $statement )
PDOStatement PDO::query ( string $statement , int $PDO::FETCH_COLUMN , int $colno )
PDOStatement PDO::query ( string $statement , int $PDO::FETCH_CLASS , string $classname , array $ctorargs )
PDOStatement PDO::query ( string $statement , int $PDO::FETCH_INTO , object $object )
 

Espero que no sea mucho pedir.

[GatorV]

Con la opción que te deje no tienes que re-escribir el método query y puedes usar todas sus variantes. O puedes ver el ejemplo que deje en este post: http://www.forosdelweb.com/f68/numer...on-pdo-804971/

Saludos.

[maturano]

Iniciado por danmichel

Mi última duda, como podría implementar el método query, que en dependencia de la variante que use invoque al método correspondiente. Pero lo que deseo es centralizarlo todo en el mismo método.

Eso se le conoce como Sobrecarga, por si no lo sabías, para que leas al respecto.

En PHP no es soportada la sobrecarga como en otros lenguajes, tendrías que simularla. La manera común y "documentada" es mediante el método mágico __call(), pero igual lo puedes hacer que un método público (query(), en este tu caso) llame a determinado método privado en función del número de argumentos pasados; esto lo sabrías con la función func_num_args(). En cualquier caso, tendrías que aplicar la lógica por tu cuenta.
www.php.net/__call
www.php.net/func_num_args

Deberías encontrar información al respecto en este mismo foro y en internet en general.


Por otra parte, se te sugirió heredar PDO precisamente para no sobreescribir los métodos si solo van a llamar al mismo método de PDO. Cuando heredas obtienes el mismo comportamiento de la clase padre. si no sobreescribes el método query(), al invocarlo tendrías la misma funcionalidad que con PDO; entendí por eso fue todo el asunto de la herencia.


Si tienes más lógica en tu método, más allá que del simple paso de parámetros, igual considera que podría no ser buena idea aquello de "tener todo centralizado en un solo método". Si el comportamiento va a ser distinto de acuerdo al paso de parámetros, podría ser buena idea hacer clara esa distinción manejando métodos públicos para cada caso. No tengo claro cuál sea tu objetivo, pero suele ser un error común de diseño el que pretendiendo tener una API simple se termine con código complejo, rebuscado, poco reusable y difícil de mantener. Solo, cuidado con ello.

Nuevamente, si tu código es tal cual lo presentas aquí, la sobre-escritura no es necesaria si se implementa la herencia.