PHP 5.2 vs PHP 5.3 parámetros por defecto

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