PHP 5.2 vs PHP 5.3 parámetros por defecto

[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”.