Solicitud de orientacion

[Triby]

Estoy reescribiendo mis codigos y entrando mas de lleno a POO, por lo que me gustaria que me den opiniones sobre lo que estoy trabajando para saber si voy bien o me regreso:

1- Clase principal: Aqui cargo toda la configuracion y tengo funciones generales para manejo de mensajes, errores, redirecciones, etc.
2- Clase abstractas base donde creo funciones que usan la instancia de la clase principal, con el fin de evitar al maximo el uso de global $clase; (claro, fuera de la base )
3- Clases abstractas (model, view, controller) que extienden la clase base y que incluyo solo funciones especificas para cada capa.
4- Clase especifica (model, view, controller) para cada modulo.

Ejemplo:

Código PHP:

// Clase general
class principal {
    private $_models = array();
    public function __construct() {}
    // Obtener o crear instancia de un modelo
    public function getModel($model) {
        if(!isset($this->_models[$model])) {
            $file = "ruta/{$model}.model.php";
            $class = $model . 'Model';
            // try-catch para incluir el archivo
            // Verifico que exista la clase
            $this->_models[$model] = new $class();
        }
        return $this->models[$model];
    }
    // Crear archivo de cache
    public function saveCache($file, $contents) {
        // Guardo todo en un archivo
    }
    // Manejo de errores
    public function error($msg) {
        die($msg); // Es solo un ejemplo
    }
}
 
// Clase base para tener acceso a funciones generales en modelo, vista y controlador
class base {
    protected function __construct() {}
    public function error($msg) {
        global $principal;
        $principal->error($msg);
    }
}
 
// Clase para modelos
class myModel extends base {
    protected function __construct() {}
    public function saveCache($file, $contents) {
        global $principal;
        $principal->saveCache($file, $contents);
    }
}
 
// Modelo para configuracion del sistema
class configModel extends myModel {
    private $_config = array(); // Acceso y modificacion con getter y setter
    public function __construct() {
        // Cargo la configuracion desde la base de datos
        // Si algo falla:
        parent::error('No se puede cargar la configuracion.');
    }
    public function saveConfig($newValues) {
        // Guardo los nuevos valores de configuracion
        // Guardo todo en archivo de cache
        parent::saveCache('config', $this->_config);
    }
}
 

Ok, ese es el resumen de lo que llevo hasta ahora, por el momento tengo la clase para conexion y manejo de base de datos "por fuera" y tengo que estar usando global $db; para tener acceso a sus metodos.

Todos los comentarios y sugerencias son bienvenidos. Gracias.

[Triby]

Despues de iniciar el tema tuve la duda de si usar parent::funcion(); para ejecutar los metodos heredados era correcto o debia usar self::funcion(); o, incluso $this->funcion(); y, probando me di cuenta que las 3 formas funcionan.

La pregunta es: Cual de las 3 opciones es la mas apropiada?

Nota: No edite el inico del tema porque me parecio que la pregunta es importante como para estar en otro mensaje, pero no en un tema aparte.

[masterpuppet]

Que tal Triby,

a ver:

1 - los modelos no deberian redireccionar, en todo caso lanzar una excepción o guardar el error y que el controller compruebe el estado para decidir que hacer.

2 - global state, mala palabra, yo lo trataría de evitar, podrías refactorizar a algo así:

Código PHP:

class Base 
{
    protected $_principal;
 
    public function __construct(Principal $p)
    {
        $this->_principal = $p;
    }
 
    public function error($msg)
    {
        $this->_principal->error($msg);
    }
}
 

y si no queres estar pasando Principal en cada una de las clases, podes hacer un fallback a registry, claro tendrias que tener registry :), pero es algo simple de construir ,

Código PHP:

public function __construct(Principal $p = null)
{
   if(null === $p) {
        $p = $this->_getDefaultPrincipal();
    }
   $this->_principal = $p;  
}
 
protected function _getDefaultPrincipal()
{
    if(!Registry::has('principal')) {
        throw new ModelException(/**/);
    }
    return Registry::get('principal');
}
 

Aclaración: esto también oculta dependencias, lo ideal seria utilizar DI.

3 - no entiendo bien, queres hacer una clase base(Object) para todos, modelos, vista y controladores ?

4 - Si cada uno debería tener su clase base especifica.

Con respecto a parent, this y self:

1. parent hace referencia a la clase base
2. this hace referencia a la instancia actual
3. self hace referencia a la clase actual

PHP lo maneja de una forma particular, pero deberías utilizar self para acceder a los miembros estáticos, en tu ejemplo yo utilizaria $this->saveCache, $this->error y parent lo utilizaría, si por ejemplo reescribiera saveCache en configModel,

Código PHP:

class ConfigModel extends Base
{
    private $_config = array(); 
 
    public function __construct() 
    {
        // Cargo la configuracion desde la base de datos
        // Si algo falla:
        $this->error('No se puede cargar la configuracion.');
    }
  
    public static function log($message)
    {...}
 
    public function saveConfig($newValues) 
    {
        // Guardo los nuevos valores de configuracion
        // Guardo todo en archivo de cache
        $this->saveCache('config', $this->_config);
        self::log('cache saved  ' .  time());
    }
 
   public function saveCache($file, $contents, $save = false)
   {
       if(true === $save) {
          parent::saveCache($file, $contents); 
       }
      ...
   }
 
}
 

Saludos.

[abimaelrc]

Una duda, ¿php no tiene una clase llamada Registry? (¿o me equivoco?). Si es así, que php no tiene una clase llamada Registry, pues como lógica tendría que crearla. Si es así, ?qué métodos recomiendas que se usen en un registry aparte de set, get y has?

Edito: Esto encontré por internet, pero no sé si es correcto, claro está no cumple con todas las recomendaciones que sugiere zend, de estandarizar el código, pero aparte de eso, ¿es todo lo que necesita o faltaría algo?

[carlos_belisario]

hasta donde tengo entendido con varias lecturas no pero aca http://desarrolladorsenior.blogspot....ry-en-php.html tienes una implementación que pudieras utilizar. saludos

[masterpuppet]

Iniciado por abimaelrc

Una duda, ¿php no tiene una clase llamada Registry? (¿o me equivoco?). Si es así, que php no tiene una clase llamada Registry, pues como lógica tendría que crearla. Si es así, ?qué métodos recomiendas que se usen en un registry aparte de set, get y has?

PHP no tiene clase Registry pero se puede utilizar como contenedor ArrayObject(Zend_Registry extiende de esta clase), para mi la clase debería tener los métodos básicos get, set, has, remove e implementar Iterator y Countable.

Iniciado por abimaelrc

Esto encontré por internet, pero no sé si es correcto, claro está no cumple con todas las recomendaciones que sugiere zend, de estandarizar el código, pero aparte de eso, ¿es todo lo que necesita o faltaría algo?

No es un Registry "puro" , es Lazy Registry(según su autor), si no te interesa esa característica, seria demasiado.

@carlos la clase que propones tiene una particularidad, se pueden crear varias instancias y todas comparten el mismo contenedor de datos, así lo hace Zend_Registry

Saludos.

[Triby]

Primero que nada, gracias a los tres por sus valiosos aportes, al parecer no estoy tan equivocado en la forma en que tengo planeado hacer esto.

masterpuppet, de acuerdo, en el modelo solamente tendria funciones de acceso a base de datos y las redirecciones deberian ser especificamente en el controlador; tengo cambiar mis habitos y aclararme un poco sobre los metodos que deben aparecer en cada objeto.

Sobre lo del registro y mis dudas entre parent:: self:: y $this->, parece que anoche al publicar el tema ya estaba medio dormido, pero hoy al levantarme me "cayo el veinte"

Al parecer, ya estoy haciendo algo similar al patron singleton + registry para los modulos cargados al tener $principal->_models y $principal->getModel()... aunque claro, necesito revisar las sugerencias para pulir y adaptar esta parte de acuerdo a sus sugerencias.

Mi confusion entre global, parent::, self:: y $this-> fue porque anoche ya estaba medio dormido, pero ahora lo tengo mas claro:

Definitivamente quiero evitar el uso de global, pero en mis primeras pruebas no funcionaba ninguna de las resoluciones de ambito, pero... era poque en principal->__construct() intentaba crear otros objetos y, obviamente, no se creaba el mismo $principal, primero tiene que salir del constructor.

Para cuando resolvi esto, en las clases base ya habia creado los metodos para tener acceso a la principal y despues fue cuando probe parent::, self:: y $this->

Porque me funcionan las 3 formas?
1- Al instanciar el modulo en $principal->_models (con el metodo $principal->getModel()) ya tengo acceso por medio de parent:: y creo que asi es como debo usarlo.
2- Lo que hace que tambien funcionen self:: y $this-> son los metodos heredados de las clases base y no son necesarios ahi.

Ahora, solo tengo que ver cuales metodos debo permitir que queden accesibles a otros objetos por medio de parent:: y cuales no.

Tambien, el objeto de acceso a base de datos lo voy a "mudar" a $principal->db.

masterpuppet, Abimael y carlos_belisario, nuevamente muchas gracias, es muy util la informacion proporcionada.

[Triby]

He estado entretenido con un poco (mucho) de lectura acerca de objetos y ahora si ya me aclare un poco mas y me retracto de las burradas que dije en el mensaje anterior:

$this-> para tener acceso a propiedades y metodos dentro del mismo objeto.
self:: para tener acceso a propiedades (?) y metodos declarados en la clase con la cual se instancio el objeto.
parent:: para tener acceso a la clase padre, de donde se extiende la actual (que dije? )

Bien, entonces, si usaba parent:: tenia acceso a los metodos por extender la clase desde base, si usaba self: tenia acceso por extender desde model, view o controler y, su usaba $self-> tenia acceso porque el metodo se hereda.

Todo esto me llevo a reecribir nuevamente todo lo que llevaba, al menos las bases de donde voy a extender para determinar el "esqueleto" de cada tipo de objeto que vaya a necesitar, aun no se como sera, pero ya llegare a ese punto.

Ahora, lo que estoy haciendo es tomar la idea de CodeIgniter para crear un "super objeto" y evitando, en la medida de lo posible, hacer recursiones aunque realmente no consume mucha memoria (segun mis pruebas, entre 150 y 200 bytes por cada objeto que incluye una propiedad que hace referencia al super objeto).

Hay muchos conceptos que aun no entiendo y logica que todavia no tengo NPI (ni la mas remota idea) de como aplicarla, pero supongo que conforme vaya avanzando y viendo como estan programados algunos frameworks y CMS ire solventandolos.

P.D. Hasta ahora solo llevo un global $variable porque incluyo un archivo desde un objeto para instanciar otro... es un problema de logica, pero como es un caso especial y fuera de cualquier objeto, lo dejare para resolverlo despues.

[masterpuppet]

Que tal Triby,

$this y parent funcionan como se espera, el que tiene un comportamiento "extraño" es self.

self no hace referencia a la clase donde se instancio el objeto, hace referencia a la clase donde se definió, (lo que conlleva a que el polimorfismo en contexto estático no sirva de nada), para solucionar esto PHP 5.3 introduce lo que se conoce como late static binding.

Con respecto al "súper objeto"(es un layer supertype con esteroides :) ?), que razón hay para que esto sea así ?, que tienen en común una vista, modelo y controller ?, entiendo que debe ser para aprovechar la "magia" de php y definir setters, getters y talvés setOptions ?, aunque la tendencia actual es cada vez menos magia y mas explicito(esto para mi es mejor).

Otra cosa, tomar CI como ejemplo no creo que sea lo más adecuado, a mi entender tiene un poco torcida la definición de hacer las cosas bien, y demasiados wtfs/m(medida estándar de calidad de código :) ), la referencia podria ser Zend, Symfony, Yii.

Por último y no te doy mas lata, deberías hacer como si global no existiera, utiliza en su lugar alguna implementación de registry + singleton.

Saludos.

[Carxl]

Me parece muy bueno @Triby que te intereses por este tema, yo ahora intento aprender patrones, porque ando algo flojo en ellos.

Quiero aprender al menos los más usados, mvc (sin framework), object, observer y saber como usarlos.

En cuanto a lo que dice @masterpuppet de CodeIgniter, lastimosamente (uso Codeigniter) tiene razón, alguna vez me dió por ver su lógica, y no fue la mejor impresión.

Ahora ando viendo Yii, Symfony nunca me gustó. Y Zend, Zend es el papá xD

Bien por ti

[Triby]

masterpuppet, no quiero extender todas las clases en base a una sola, que fue mi loca idea original, solo quiero tener una que se encargue de crear todos los objetos y conserve el acceso a ellos, por referencia y, si comparten propiedades o metodos, sera de acuerdo a las necesidades y no por herencia.

Lo del global: en config.php tengo info para conectar a base de datos, tipo, host, usuario, etc. y tengo un archivo db.php que debe verificar el tipo para poder incluir el archivo con la clase correcta, pero como proviene de una funcion donde dbHost no esta visible, opte por "global" en lugar de definir una constante que se requiere una sola vez.

Carxl, cierto, he visto cosas de CodeIgniter que no me gustan, incluso en la codificacion (aunque yo todavia no sigo un estandar en estas cuestiones). Voy a echarle un vistazo a Zend (alguna vez lo vi), a Yii (no lo conozco) y a Symfony (no recuerdo si ya lo revise).

Gracias a ambos por los buenos aportes.

Edito: Por el momento solo revisare Yii y esperare mas noticias de la nueva version para probarlo:

Iniciado por Yii Framework

While Yii 1.1.x is working extremely well, we do not want to stop here.

Our next major release Yii 2.0 will be a complete rewrite of the framework on top of PHP 5.3.0+. It will not be fully compatible with 1.1.x. However, we will try every effort to make the transition as easy as possible.

Re-edito:
Zend es un monstruoso ZIP de 25mb, ya decia yo que algo me habia mantenido alejado de el... pero bueno, todo sea por ver "sus tripas", saber como trabaja y aprender algo nuevo.

[carlos_belisario]

Interesantisimo post este de verdad, aunque mi experiencia es poca antes de la de los amigos que tienen este gran debate voy a ver si me puedo meter y aportar un poco en el tema ,

masterpuppet, no quiero extender todas las clases en base a una sola, que fue mi loca idea original, solo quiero tener una que se encargue de crear todos los objetos y conserve el acceso a ellos

No se si estoy en lo cierto o entendi bien pero creo que la solucion a esto seria que implementaras un factory, cuya razon de existencia es esa crear objetos el articulo de wikipedia creo que tiene un link a un ejemplo con PHP, en cuanto a lo de clases principales, creo que para la implementación del MVC tendrias que tener por algunas para extender por lo menos un model,controller y un view aunque yo personalmente no me he metido tan alla en este patron con ayuda de lecturas y tutoriales mas o menos he creado algunas clases base de estas y hasta ahora me ha parecido que voy mejorando en mis desarrollos aunque me falte bastante, la idea de la que hablas de una superclase creo que no eres el primero que se le ocurre a mi también se me habia ocurrido esa idea cuando comence a meterme con OOP hasta que me hicieron pisar piso y ponerme a investigar sobre algo que se llama responsabilidad unica (separacion de responsabilidades) desde ahi me siento a ver que tiene que hacer en especifico cada objeto que voy a crear, espero que le sea de ayuda lo que le indique saludos

[Triby]

Iniciado por carlos_belisario

No se si estoy en lo cierto o entendi bien...

carlos_belisario, entendiste mas o menos bien ... explico:

Originalmente estaba haciendo la burrada de extender todo desde una misma clase base.

Siguiendo las sugerencias de masterpuppet, reescribi lo que llevaba para dejar el "nucleo" como responsable de administrar cualquier objeto creado, pero sin heredar cosas que no debe; ya estoy viendo lo del metodo Factory y tambien algo sobre Namespace para considerar otras alternativas.

Aparte de esto, las clases abstractas para modelo, vista y controlador, por ahora no tienen propiedades o metodos, hasta que defina que voy a hacer y planear como lograrlo y si, definitivamente, habra un "padre" para cada uno de ellos.

Iniciado por carlos_belisario

Interesantisimo post este de verdad, aunque mi experiencia es poca antes de la de los amigos que tienen este gran debate voy a ver si me puedo meter y aportar un poco en el tema

Claro que el aporte es muy util, tanto la informacion como los puntos de vista son muy interesantes, gracias!