Duda sobre teoria de clases

[Keysher]

Tiene razón, No tengo claro nada y soy un inutil. Gracias por abrirme los ojos. Aquí se acaba toda mi relación en éste asunto y con usted.

A partir de ahora, agradecería que no me intentase ayudar. (sí, quiero seguir sin tener ni idea de nada)

Gracias por todo y hasta siempre eminencia.

(A los demás, gracias por intentar dialogar y debatir el modelo)

[enriqueplace]

Tiene razón, No tengo claro nada y soy un inutil. Gracias por abrirme los ojos. Aquí se acaba toda mi relación en éste asunto y con usted.

Es increíble, pero este tipo de respuesta por los "intermedios" se convierte en un "patrón": hacen una consulta, hablan luego de lo que no saben, se les hace ver, pero luego se ofenden, argumentan que sí saben del tema (lo cual es evidente que no), y posteriormente abandonan la discusión insultando a su interlocutor, ofendidos, como si "no saber" fuera un insulto.

El insulto es hacernos perder el tiempo con tonterías, debes comunicar tu duda y problema y todos te ayudarán, pero ponerte a decir tonterías con gruesos errores de concepto para luego defender lo indefendible, no es aceptable.

Si no sabes, lo solucionamos, pero no sigas tratando de tapar una tontería con otra.

A partir de ahora, agradecería que no me intentase ayudar. (sí, quiero seguir sin tener ni idea de nada)

El problema eres tú, no aceptas las ayudas. Para aprender hay que dejar el orgullo de lado.

Gracias por todo y hasta siempre eminencia.

(A los demás, gracias por intentar dialogar y debatir el modelo)

No has dejado de insultar a tu interlocutor.

Si quieres aprender debes aceptar cuando te equivocas y saber escuchar lo que no te gusta que te digan, no puedes esperar a que te digan lo que esperas, más si estás equivocado.

[Casuis]

Básicamente es un problema de composición. Es decir, las clases no tiene carácteristicas de "parentesco" pero lógicamente la Clase coche contiene Ruedas.

Es decir está compuesta de ruedas.
La composición de objetos se utiliza para encapsular los atributos del objeto que a su vez representa un atributo en la clase que se compone. Así la clase coche puede utilizar este objeto para ampliar operaciones.

Imaginate que queremos saber el precio total de las ruedas que tiene nuestro coche.
Un objeto rueda puede tener un precio unitario, cada objeto su precio. La rueda marca michelin valdrá 10 pero la pirelli valdrá 20.
Si suponemos que un coche tiene 4 ruedas y las dos delanteras son michelin y las dos traseras pirelli como haremos para saber su precio.
Pues utilizaremos la composicion de ruedas para definir un metodo en la clase coche que calcule el coste independientemente de la Rueda.

Ahora pasamos al caso practico:

clase Rueda:

Código PHP:

  class Rueda
{
    private $_marca;
    private $_model;
    private $_precio;
    
    public function __construct($marca, $modelo ,$precio)
    {
        $this->_marca  = $marca;
        $this->_modelo = $modelo;
        $this->_precio = $precio;    
    }    
    
    public function getMarca(){
        return $this->_marca;
    }
    
    public function getModel(){
        return $this->_modelo;
    }
    
    public function getPrecio(){
        return $this->_precio;
    }
}  
   

clase Coche:

Código PHP:

  class Coche{
    
    private $_nombre;
    private $_ruedas = array();
    
    public function __construct($nombre){
        $this->_nombre = $nombre;
    }
    
    public function getNombre(){
        return $this->_nombre;
    }
    
    public function addRueda(Rueda $rueda)
    {
        if(count($this->_ruedas)<4)
            $this->_ruedas[] = $rueda;
    }
    
    public function getTotalCosteRuedas()
    {
        $precio = 0;
        foreach($this->_ruedas as $rueda){
            $precio += $rueda->getPrecio(); 
        }
        return $precio;
    }
    
    public function getNumeroRuedas(){
        return count($this->_ruedas);
    }
    
}  
   

Ahora para hacemos unas intancias para ver lo expuesto:

Código PHP:

  $coche = new Coche('ford');
$coche->addRueda(new Rueda('Pirelli','p600',20));
$coche->addRueda(new Rueda('Pirelli','p600',20));
$coche->addRueda(new Rueda('Michelin','gc400',10));
$coche->addRueda(new Rueda('Michelin','gc400',10));

echo "El coche: ". $coche->getNombre() . "<br />";

echo "contiene: ". $coche->getNumeroRuedas() 
     . " ruedas con precio: " . $coche->getTotalCosteRuedas();  
   

La salida será la siguiente:

Código:

El coche: ford
contiene: 4 ruedas con precio: 60

Como ves podemos saber el precio del total de ruedas independientemente del tipo de rueda que use.
Espero haberte aclarado algo. Si aun te quedas con dudas exponlas estamos para ayudar

[GatorV]

y con esto volvemos al problema inicial, que es que él no quiere que las ruedas se puedan instanciar solas jeje, por eso la recomendación de "crearlas" desde Carro...

Pero buen aporte Casius

[Casuis]

Y mi pregunta es: por que no?

Chicos una de mis primeras premisas si lo puedes hacer simple hazlo simple.

[GatorV]

Exacto, era lo que todo mundo discutia si era correcto o no el "denegar" el crear la clase (a mi parecer le da flexibilidad al sistema... pero pues ahora si que cada quien).

Saludos Casius, que bueno verte por aqui

[Keysher]

Coincido en que en la mayoría de los casos ese planteamiento es el correcto.

De hecho reconozco que estaba equivocado en algunas de las premisas, había errado en el análisis inicial.

Pero sigo creyendo que en un caso concreto no me interesa que el objeto se cree por sí mismo.

Tenemos una clase parecida a esta (es muy básica):

Código php:

class Template {
    private $templateName;
    private $vars;
    private $templateFile;
 
    function __construct($auxTemplate, $auxFile) {
        $this->templateName = $auxTemplate;
        $this->templateFile = $auxFile;
        $this->vars = array();  
    }
 
    public function setVar($auxVar, $auxValue) {
        if (!array_key_exists($auxVar, $this->vars))
            $this->vars[$auxVar] = $auxValue;
    }
    public function getVar($auxVar=NULL) {
        if ($auxVar == NULL)
            return $this->getVars();
 
        if (!array_key_exists($auxVar, $this->vars))
            return NULL;
 
        return $this->vars[$auxVar];
    }
            
    public function getTemplate() {
        return $this->templateName;
    }
            
    public function getFile() {
        return $this->templateFile;
    }
            
    public function getVars() {
        return $this->vars;
    }
}
 

Para instanciarla se necesita un nombre de plantilla y un fichero asociado, y eso lo tengo en un array dentro de otra clase.

Código php:

class Style {
 
    
    private $style;
    private $templates;
    private $cssFiles;
    private $jsFiles;
    private $currentTemplate;
    private $basePath;
    private $preparedTemplates;
        
    function __construct($auxStyle, $auxStyleConfigFile, $auxStylePath) {
 
(...)
    }
 
    public function selectTemplate($auxTemplate) {
        if (isset($this->templates[$auxTemplate])) {
            $auxPath = $this->basePath.$this->templates[$auxTemplate];
            if (file_exists($auxPath)) {
                $this->emptyTemplate();
                $this->currentTemplate = new Template($auxTemplate, $this->templates[$auxTemplate]);
            } else
                trigger_error($this->msgError['TEMPLATE_FILE_NOT_FOUND'].$auxTemplate, E_USER_ERROR);
        }
        else    
            trigger_error($this->msgError['TEMPLATE_NOT_FOUND'].$auxTemplate, E_USER_ERROR);
    }
 
    public function addVar($auxVar, $auxValue) {        
        if (isset($this->currentTemplate)) {
            $this->currentTemplate->setVar($auxVar, $auxValue);
        } else
            trigger_error($this->msgError['TEMPLATE_NOT_SELECTED'], E_USER_ERROR);
    }
 

Entiendo que es menos flexible esta forma y que es más costoso hacer cambios en el código. Pero tampoco veo muy lógico el tener que sacar primero el nombre de la plantilla y su fichero de la clase Style, para crear luego un objeto de la clase Template con estos datos, y añadirlo a la primera clase.

Entonces, ¿debo cambiar la forma en la que se crea la clase Template? ¿lo dejo como está pero creo otro método para atar un Template creado al Estilo?

Gracias!

[venkman]

¿Por qué está selectTemplate dentro de Style?

¿Por qué Style necesita manejar los nombres de fichero de las Template? ¿Lo utliza para algo más que para instanciarlas? ¿No debería el fichero ser una preocupación propia de Template?

selectTemplate -el nombre- y el hecho de que Style maneje una colección de Templates me sugiere la acción de seleccionar una Template entre varias ya existentes, pero selectTemplate está realmente creando una instancia nueva cada vez que se llama. No sólo eso, sino que encima hace una validación de existencia de un fichero. ¿Realmente cuál es el objetivo de selectTemplate?

Por lo que veo, en realidad Style ni siquiera maneja una colección de Templates, sino que maneja únicamente un array de nombres de ficheros. ¿Por qué?

[Keysher]

Bueno, la clase Style está muy simplificada, en el constructor lee un fichero de configuración del estilo, y de ahí carga los nombres de los templates con sus respectivos ficheros (entre otros datos).

SelectTemplate selecciona uno de ellos para trabajar con él, cuando se ha terminado de agregarle variables hay un método que pasa el objeto a otro array.

[venkman]

Si he planteado todas esas cuestiones es porque no creo (mi opinión) que esos detalles estén correctamente diseñados y solucionados. Por supuesto con las limitaciones de ver sólo parte del código, claro (así que puedo equivocarme).

Yo creo que Sytle no debería tener que manejar los nombres de ficheros de las Templates; esa es una propiedad de Template y por eso debería ser Template quien lo maneje. Igualmente creo que selectTemplate está haciendo demasiadas cosas que no le corresponden y que Style debería tener directamente los objetos Template no un array con los nombres de los ficheros.

[Keysher]

El caso es que cada Estilo tiene un fichero de configuracioń, de donde se cargan los datos necesarios (nombres de plantillas, sus ficheros, css necesarios, etc...). Esto hay que leerlo al crear un estilo, pero no me interesa crear un objeto de la clase Template para todos los elementos, ya que no se usarán todos. Entonces mediante la clase Style se puede decir qué template se quiere usar.

¿Cómo plantearías un sistema en el que la clase Template fuera la que maneja el fichero y el nombre? Esos datos son propios del estilo.

Podría crear todos los objetos Template al crear un estilo, pero como he dicho no me interesa, ya que sólo manejaré los que sean necesrios.

Edito:
La idea de hacer las comprobaciones en la clase Template también es válida, de hecho debería hacerlo así si se va a dejar que se cree la clase por sí sola.

[GatorV]

Mmm creo sería interesante si nos presentas el diagrama UML de esto que quieres realizar.

Saludos.

[Keysher]

Umm, ahí me has pillado... no lo tengo aquí.


Pero supongamos dos clases:

Código:

Template:

	private $templateName;
	private $vars;
	private $templateFile;

	__construct($auxTemplate, $auxFile)
	public function setVar($auxVar, $auxValue)
	public function getVar($auxVar=NULL)
	public function getTemplate()
	public function getFile()
	public function getVars()


Esta clase es bastante simple, tiene el nombre de una plantilla, su fichero físico (incluido el path relativo) y una serie de variables que serán las que se meterán en la plantilla.



Style:

	private $style; //nombre del estilo
	private $templates; //lista con los templates de ese estilo
	private $cssFiles; // Lista de ficheros css de ese estilo
	private $jsFiles; // Lista de ficheros javascript de ese estilo
	private $currentTemplate; //template seleccionado actualmente para trabajar con él.
	private $basePath; //el path base del estilo
	private $preparedTemplates; //array donde se irán almacenando las plantillas preparadas para mostrar
	(otras variables de configuración)



	function __construct($auxStyle, $auxStyleConfigFile, $auxStylePath)
	private function loadStyleConfigFile($auxPath) // Carga el fichero de configuración (se llama desde el constructor)
	
	getters y setters...
	
	public function existsTemplate($auxTemplate) // Comprueba que una plantilla existe en ese estilo (está cargada en el array de nombres => ficheros)	
	public function emptyTemplate() //Vacía currentTemplate
	public function selectTemplate($auxTemplate) //Crearía un objeto de la clase Template en base a los datos propios del estilo (el fichero del template, el path base...)
	public function prepareTemplate() // añade la plantilla a un array de Templates que ya se han "preparado"
	public function addVar($auxVar, $auxValue) // agregaría una variable a la plantilla actual <- Puede que por éste método me crucifiqueis!
	private function requireTemplate($auxPath, $vars) // Este método es el que hace un require del fichero para agregar las variables y devuelve el HTML resultante. (Puede que estuviese mejor en la clase Template)
	public function showCurrentTemplate()		
	public function showTemplate($auxTemplate)
	public function showAll()

Más o menos sería algo parecido.... Creo que sé cómo es el sistema que me planteais (que es el que uso en la relación entre otras clases), lo que no veo del todo claro es que en éste escenario sea la mejor opción. Soy consciente de las limitaciones (bueno, quizás no totalmente consciente y por ello no lo veo tan claro).


La idea es que se cargue un estilo. Entonces en el fichero de configuración se especifican todas las plantillas que tiene, sus archivos, los ficheros css o js que utiliza, los paths, etc...

Una vez que tenemos un objeto de esta clase, trabajamos con las plantillas, una o varias. Tal y como está planteado sólo se podría usar una en cada momento (pero esto se podría cambiar). Cuando se selecciona una plantilla para trabajar con ella, se crea el objeto de la clase Template.

Ahora se van agregando las variables que se mostrarán en esa plantilla. Una vez que estén listas, la metemos en un array de la clase estilo.

Si queremos trabajar con otro template, el proceso es el mismo.

Cuando están preparadas todas las plantillas de ese estilo, podemos usar el método showAll (mal nombre, cierto), que lo que hace es evaluar las plantillas preparadas para generar la salida HTML, que se le devolverá a una tercera clase... pero ese es ya otro asunto!!

Entiendo que puede no estar bien especificado, pero es la forma en la que lo ideé. Si lo hiciese perfectamente me dedicaría a ello profesionalmente!

Saludos y gracias por "perder" el tiempo con esto!

[venkman]

Sólo me da tiempo a contestar una cosa:

Iniciado por Keysher

¿Cómo plantearías un sistema en el que la clase Template fuera la que maneja el fichero y el nombre? Esos datos son propios del estilo.

En mi opinión no. Lo que será propio del Style es qué Templates usa (sus identificadores), pero el fichero que corresponde a una Template claramente es un dato propio de la Template.

(Vamos, si es que estoy entendiendo bien a qué te refieres con Style y Template, claro)


Bueno, y me da tiempo a contestar otra: Ningún tiempo es perdido :)

[Keysher]

Vale, sí son datos que afectan a las plantillas, pero pertenecen a la configuración del propio estilo. Cada estilo tendrá un fichero donde especificará sus plantillas y sus ficheros asociados.

Por eso los guardo en un array dentro de estilos, para que alguien pregunte: "ey, ¿existe la plantilla X en éste estilo? ¿sí? pues vamos a cargarla!"

La otra forma sería crear los objetos correspondientes a todas las plantillas cuando se crea un estilo, Entonces en vez de un array con nombres y ficheros de plantilla, tendría un array de objetos de la clase template. Pero no me parece la mejor opción, un estilo puede tener un montón de plantillas, pero sólo me interesa trabajar con una o dos simultaneamente.

[Lord Kazuky]

Porque en alguna parte del "sistema" (Donde tu quieras) no se podria hacer algo como esto?:

Código PHP:

  $objStyle = new Style();
(...)

$objTemplate = new Template($nombreArchivo);
if(!$objTemplate->loadTemplate() ){
    echo("Ocurrio un Error al cargar la plantilla.". $objTemplate->error );
    return false;
}
(...)

// Asocias el objeto 'Template' como tu quieras al objeto 'Style'
$objStyle->useTemplate($objTemplate);  
   

Naturalmente con los cambios necesarios en las clases, pero en esencia no es eso lo que deberia hacer? (Bueno segun lo que entendi )

[Keysher]

Sí, sí se puede hacer eso. Pero ese $nombreArchivo lo sacaría de la propia clase Style (ya que los nombres de los archivos los carga de un fichero de configuración al crear un objeto de esa clase).

Entonces la secuencia sería:

Código php:

$objStyle = new Style();
 
$templateFile = $objStyle->getTemplateFile('nombre_plantilla');
 
$objTemplate = new Template('nombre_plantilla', $templateFile); //en esl propio constructor se podría hacer el loadTemplate
 
$objStyle->addTemplate($objTemplate);
 

Eso (o algo parecido) funcionaría bien, pero es más costoso y hay más posibilidades de cometer errores...

La pregunta es ¿sería lo más correcto usar éste método?

[GatorV]

¿Que problema hay de hacerlo como te expuse en mi primer post? Deja que getTemplateFile sea getTemplate (internamente llama a getTemplateFile) y devuelves un objeto del tipo Template.

Saludos.

[Keysher]

Umm, ¿te refieres a crear el objeto desde un método de Style? A mi eso me parece bien, de hecho lo prefiero... pero estabámos dando muchas vueltas sobre su utilidad...

Por mi lo dejaría así (simplifiando):

Código php:

class Style {
    private templates = array(); // contiene: nombre_plantilla => fichero_plantilla
    private template;
    public function createTemplate($auxTemplateName) { //recibe una cadena con el nombre del template a crear
        $this->template = new Template($auxTemplateName, $this->templates[$auxTemplateName]);
    }
    public function addTemplate($auxTemplate) { //recibe un objeto Template ya creado.
        $this->template = $auxTemplate;
    }
}
 

El caso es que todo el mundo coincide en que es mejor crear el objeto desde fuera de la clase. La duda sigue siendo cuál es el mejor método.

[GatorV]

Todo depende del uso, si lo vas a atar de la forma que lo requieres, mejor hazlo desde dentro de la clase, pero dejalo abierto para poderse ingresar, por ejemplo, en mi DataGrid, tienes dos posibilidades, pasarle un Formatter desde fuera, o usar el integrado (iniciado desde dentro de la clase).

Entonces puedes hacer algo asi (atamos una instancia externa):

Código php:

$formatter = new Gecko_Datagrid_Formatter();
$DataGrid = new Gecko_Datagrid( 'grid1', $settings, $formatter );
 

ó:

Código php:

$DataGrid = new Gecko_Datagrid( 'grid1', $settings );
$formatter = $DataGrid->getFormatter();
 

La clase al no detectar que hay un formatter "valido", crea uno por defecto dentro y te regresa la instancia atada a ese grid, ya que en este caso un formatter sin un grid no sirve de nada (patrón decorador).

Por eso te decia, deja la flexibilidad al programador de las dos formas, yo en mi caso lo dejo abierto para quien lo quiera usar, dando métodos como getFormatter(), setFormatter(), instanciandolo desde el constructor, o pasandolo como parámetro en el $settings array.

Si quieres ver como esta implementado date una vuelta por la pagina de GoogleCode.

Saludos.

[Keysher]

Creo entender las dos formas. Le he echado un vistacillo al código en GoogleCode y tiene buena pinta.

Pero tengo una duda:
En el segundo caso, cuando llamas a getFormatter, te devuelve el objeto, pero... ¿si modificas $formatter se modifica también dentro de $DataGrid?

[GatorV]

Así es, ya que en PHP5, los objetos se devuelven por referencia, y esta pensado para que hagas cosas así:

Código php:

$formatter = $DataGrid->getFormatter();
$formatter->skipColumns( array( 'col1', 'col2', 'col3' ) );
$formatter->setColumnNames( array( 'col4' => 'Columna4' ) );
echo $DataGrid;
 

Si te fijas al modificar $formatter se reflejan los cambios directo en el Grid.

Saludos.

[Keysher]

No sabía que los objetos se devolvían por referencia!!! Eso simplifica mucho las cosas.

Resumiendo un poco como planteo mi caso:

- Un método en Style creará un objeto de la clase Template y lo añadirá a un array dentro de la propia clase Style

- Otro método de esa clase permitirá "atar" un objeto de la clase Template ya creado al array de la clase Style (éste método hará unas comprobaciones para ver si la plantilla que se intenta pasar es válida)

Cuando tenga algo más o menos usable (algo simple y básico, sin muchas pretensiones), lo publicaré para que sea "fusilado".

Gracias a todos y saludos!!

[enriqueplace]

Iniciado por Keysher

No sabía que los objetos se devolvían por referencia!!! Eso simplifica mucho las cosas.

Y después te enojas cuando te decimos que estás equivocado y te faltan conocimientos base para poder hacer las cosas bien.

[AnisDelMono]

El insulto es hacernos perder el tiempo con tonterías, debes comunicar tu duda y problema y todos te ayudarán, pero ponerte a decir tonterías con gruesos errores de concepto para luego defender lo indefendible, no es aceptable.

La contradiccion es una de las bases de la evolucion.

Disculpen, un comentario... por qué no dejan de jugar con los objetos? veo que en cualquier momento se pueden sacar un ojo.

Nadie va a perder un ojo jugando con POO! Estas metaforas baratas! El dia que pases una guerra no se que vas a decir! Si es facil! Es cuestion de meter los codos. Y si uno se equivoca, pues lo vuelve a hacer!

Seran positivos y generosos. Si son tan perfectos pero incapaces de reconocer a alguien que se esfuerza, a su manera, de entender el POO, mejor no participen en el foro.

Agradecer a Keysher este post. Se aprende mucho de alguien que idem.

Cuidense

[enriqueplace]

AnisDelMono, veo que no es tu fuerte la ironía ni el humor.

En otras palabras (creo que está muy claro en el hilo de la discusión) lo de "no juegues con POO" significa que sin fundamentos no se llega a nada. Probar por probar es una perdida de tiempo, es ridículo.

Evidentemente, por falta de humildad, se fueron tirando "errores gruesos de conceptos" que una vez evidenciados fueron defendidos por el susodicho "a capa y espada", por lo que en lo personal prefiero que digan "no sé" a que digan "si sé", "hacer años estoy en esto", "tengo título de ingeniero", "me llamas ignorante", "sé de POO", etc.

La idea es tirar las preguntas correctas, no tratar de demostrar algo que no existe.

Como venir a insistir "eso lo sé" y luego sorprenderte que PHP5 maneja los objetos por referencia y no por valor.

[CAT Shannon]

enriqueplace, creo que te olvidas de uno de los principios básicos de la informática:

A menudo unas horas de "prueba y error" ahorran unos minutos de leer manuales.

[enriqueplace]

Me imagino que me lo dices en broma, no?

Como el dicho "si todo falla, hay que leer el manual".

[GatorV]

Este tema ya se extendio demasiado, y esta llendose a ningún lado productivo, y/o orientado a PHP.

Tema cerrado.