Metodo estatico que sepa el nombre de la clase que lo llama

[Volrath]

Hola. No soy un usuario comun de PHP, tengo mucho tiempo sin trabajar en él (desde los inicios de php4), y tengo algunas dudas con el manejo de OOP en PHP5.

Estoy haciendo algo de esta forma:
Tengo una clase Basic de la que heredan muchas clases las cuales no se su nombre a priori. Quiero que esas clases tengan un metodo estatico en comun y que cuando esté en ese metodo, pueda saber que clase lo llamo. es algo asi:

Código:

<?php

class Basic {
  ...
  public static unMetodo() {
    echo "Fui llamado desde la clase " . self . "\n";
  }
}


class Clase1 extends Basic { ... }
class Clase2 extends Basic { ... }
...
class ClaseN extends Basic { ... }

Clasei::unMetodo() // Aqui deberia imprimir: "Fui llamado desde la clase Clasei"

sin embargo usando unicamente la palabra self no lo logro, ni tampoco get_class(self).

Intente otras alternativas, como por ejemplo:

Código:

class Basic {
  public static $class_name;
  ...
  function __constructor() {
    $this->class_name = get_class(this);
  }
  ...
  public static unMetodo() { echo "Fui llamado desde la clase " . self::$class_name ; }
}

Se que es posible que haya una forma mas facil de realizarlo, pero repito, no estoy muy familiarizado con PHP5 jeje.
Alguien tiene alguna idea?

[GatorV]

Hola Volrath,

self siempre se refiere a la clase en la que fue definida la función, puedes probar usando __CLASS__.

Saludos.

[Volrath]

No funciono, pero me dio una idea para la solucion, y ya todo funciona. Gracias!

Aqui dejo la solucion por si alguien mas la necesita:

Código:

// Primero el problema.
class Basic {
  public static muestraMiNombre() {
    echo __CLASS__;
  }
}

class A extends Basic { ... }
class B extends Basic { ... }

A::muestraMiNombre() // imprime 'Basic'
B::muestraMiNombre() // imprime 'Basic'

Código:

// Ahora la solucion:

class Basic {
  public static $class_name;

  public function __constructor { self::$class_name = get_class($this) }

  public static function muestraMiNombre() {
    echo self::$class_name;
  }
}

class A extends Basic { ... }
class B extends Basic { ... }

A::muestraMiNombre() // imprime 'A'
B::muestraMiNombre() // imprime 'B' =)

Espero que a alguien le sea util
bye!

[GatorV]

Hola Volrath,

Muy buena solucion, aunque tienes la limitante de que debes de crear me supongo el objeto antes de usarlo no?

Saludos.

[enriqueplace]

Dos comentarios:

• No es necesario (ni recomendable) que el atributo sea público.
• ¿para qué caso práctico puedes necesitar preguntar por la clase? Justamente, el beneficio está en no atar al sistema a "implementaciones concretas" y sí a "implementaciones abstractas" (principios de diseño).

[Volrath]

Iniciado por enriqueplace

Dos comentarios:

• No es necesario (ni recomendable) que el atributo sea público.
• ¿para qué caso práctico puedes necesitar preguntar por la clase? Justamente, el beneficio está en no atar al sistema a "implementaciones concretas" y sí a "implementaciones abstractas" (principios de diseño).

Hola, en cuanto a tu primer punto, no estoy seguro de porque dices q no es recomendable que el atributo sea publico, en mi caso en particular, yo no lo utilizo como publico sino como protected. Pero me gustaria saber porque piensas que no es recomendable que el atributo sea publico

En cuanto al segundo, creo que como no di un contexto amplio de que es lo que estoy implementando te confundiste y piensas que no existe caso practico de interes.

Voy a colocar un escenario corto (no mi escenario particular) en el cual es util: Estas construyendo un ORM, Sigues la convencion de que las clases se llamaran igual que las relaciones.

Digamos que, ademas de las comunes tareas de hacer que las instancias de tus clases puedan guardarse, actualizarse y borrarse de la base de datos por si mismas, ahora quieres que tus clases (que representan relaciones) puedan funcionar de managers de las relaciones. Es decir, ahora quieres tener metodos de clases (o como php5 los llama: metodos estaticos) para poder actuar sobre todas las instancias y todas las tuplas de las relaciones en la BD.

Quieres que tu tabla/clase pueda hacer cosas como: Persona::obtenerTodas() y que esto te devuelva tantos objetos instancias de la clase Personas como tuplas haya en la relacion PERSONA de la base de datos. pero ahora ademas tienes: Casa::obtenerTodas() , Carro::obtenerTodas()... etc... se supone que por "desiciones de dise;o" no quieres implementar estos metodos en todas las clases que declares, Por lo tanto quieres una superclase que lo tenga, llamemosla Modelo. Ahora, para el metodo Modelo::obtenerTodas tenemos que saber cual es el nombre particular de mi (sub)clase para poder decirle a la base de datos sobre cual tabla en particular queremos ejecutar el query (en este sencillo ejemplo: SELECT * FROM $class_name)

Esta es solo una de las utilidades practicas.. No es que ahorita este construyendo un ORM, pero es el ejemplo comun que se suele dar para este tipo de requerimientos.

----

En cuanto a lo que escribio GatorV: Hola! Gracias. No entiendo lo de la limitante de crear el objeto antes de usarlo :$, no estoy muy seguro de las cosas en PHP, repito jeje. Pero hasta los momentos no me ha ido mal con esa implementacion.

Gracias a los dos por sus respuestas!

[enriqueplace]

Iniciado por Volrath

Hola, en cuanto a tu primer punto, no estoy seguro de porque dices q no es recomendable que el atributo sea publico, en mi caso en particular, yo no lo utilizo como publico sino como protected. Pero me gustaria saber porque piensas que no es recomendable que el atributo sea publico

Primero, en todos los ejemplos que nos muestras usas un atributo público, por consiguiente "no me puedo equivocar".

Código PHP:

  public static $class_name;  
   

Segundo, como principio general y básico de la POO, no se usan nunca atributos públicos, a lo sumo, métodos "getters y setters" (no lo digo yo).

Iniciado por Volrath

En cuanto al segundo, creo que como no di un contexto amplio de que es lo que estoy implementando te confundiste y piensas que no existe caso practico de interes.

Voy a colocar un escenario corto (no mi escenario particular) en el cual es util: Estas construyendo un ORM, Sigues la convencion de que las clases se llamaran igual que las relaciones.

Nuevamente, subestimas el poder de la fuerz... digo, de mi entendimiento . Son muy pocos los casos que puedas verdaderamente necesitar saber la clase, un caso *muy* particular es hacer un ORM, pero para el resto *generalmente* es una mala decisión de diseño atarte a preguntar "cual es la clase que estoy procesando" y no hacer algo genérico (buscar en Google patrón de diseño abierto cerrado).

¿Por qué? Por principios básicos de diseño POO, porque no utilizas el "patrón estratégico más importante de la POO" que es el Polimorfismo.

Recomendación: busca material en Google sobre "Liskov herencia de clases y principio de sustitución".

PD: hay un principio que dice "si me cambias de contexto, tengo que cambiar de solución"; si planteas algo, te responderemos en base a ese planteo, pero si luego nos dices "que tu contexto es otro", no pidas que la misma respuesta sirva para algo que ni siquiera nos lo presentas.

Esto no es una competencia de "quién sabe más" y tú no estás en evidencia por "no saber" (no hace falta que te defiendas) pero respeta el tiempo de los demás que buscan darte una mano, por lo menos habla claro y sé franco.

[pateketrueke]

weno... se debe a que $this es una variable y NO una constante como lo haces.... solo usa correctamente get_class($this) .... OJO con el this!

[Volrath]

Hola de nuevo, enrique.

Antes de empezar a escribir voy a colocar los motivos del por que lo hago, solo porque estoy viendo que esto se esta poniendo "intenso" y desde un principio esto no era lo que yo queria buscar.

1. Respondo porque me parece interesante tener puntos de vista de tu parte ya que (aunque tu mismo lo niegas, contraproducentemente) me has demostrado que sabes del tema y me es util aprender de lo que tengas que decir.

2. Porque la primera mitad de tu anterior post me sono con una actitud respetuosa con ganas de debatir un punto de vista. Bueno, quizas debatir no sea la palabra correcta, mas aun: imponer o dar a conocer, pero por no faltar el respeto, digamos: compartir.

3. Porque la segunda mitad de tu anterior post me sono irrespetuosa y arrogante, y porque a pesar de que considero que es una mala forma de expresarse, trato de ver el fondo y no la forma. En el fondo veo ideas validas y de nuevo ganas de compartir con todos y mostrarnos el hecho de que sabes un tema especifico.

4. Porque ya termine lo que estaba haciendo, y ahora tengo un poco de tiempo para compartir ideas con otras personas. Podriamos compartir el codigo que realice si asi quisieras.. si aun tienes mas ganas de ayudarme ;)..

---
Dicho esto, procedo con la respuesta al mas puro estilo que has tomado tu anteriormente :P..

Iniciado por enriqueplace

Primero, en todos los ejemplos que nos muestras usas un atributo público, por consiguiente "no me puedo equivocar".

Primero: Recomendaria que consideraras leer de nuevo lo que citaste de mi post anterior y tu respuesta, porque la veo esquiva, y si no es esquiva entonces probablemente <ironia>el nivel de tu fuerz.. entendimiento, supere ampliamente el mio</ironia> porque de verdad que dijiste con relacion escasa.
Segundo: Los ejemplos que puse eran eso, ejemplos. Y estaban hecho solo con el interes de dar a entender mi idea, como obviamente tu, y el amigo GatorV (gracias de nuevo) lo hicieron. Quizas si te fijas bien en el codigo que escribi, te podras dar cuenta que no era codigo de verdad, solo un peque;o ejemplo hecho "live" sobre este textbox para poder expresar un mensaje. Podras leer mas de este punto al final.

Ademas, te repito, a pesar de tu arrogancia, estoy interesado en saber que piensas acerca de este punto, solo por aprender de las ideas de otras personas que parecen ser estudiadas en el ambito.

[
Aqui voy a colocar una nota intermedia, que valida para todos los siguientes puntos: Ahorrate hablar de setters, getters y de principios basicos de OOP. No soy una persona altamente experimentada en el ambito pero llevo cierta experiencia, y tus comentarios, aunque quizas constructivos, pueden sonar degradantes. De ahora en adelante puedes asumir, si tu arrogancia asi te deja, que estas hablando con alguien que entiende de lo "basico" y eso nos ahorrara tiempo a los dos. Lo digo solo para evitar mal entendidos :).
]

Nuevamente, subestimas el poder de la fuerz... digo, de mi entendimiento .

Solo para dejar claro el porque estoy pegado con lo de la arrogancia ;). Creo que aqui hay una confusion de papeles. Creo que el que subestima al otro eres tu, no yo. Sin embargo, a diferencia de ti, yo no espero que me tengas muy alta estima, no mas de la que mis palabras te han demostrado ;) piensalo.

Son muy pocos los casos que puedas verdaderamente necesitar saber la clase, un caso *muy* particular es hacer un ORM, pero para el resto *generalmente* es una mala decisión de diseño atarte a preguntar "cual es la clase que estoy procesando" y no hacer algo genérico (buscar en Google patrón de diseño abierto cerrado).

Lo positivo de este punto es que estamos de acuerdo que no SIEMPRE es una mala decision de diseno, porque hay casos particulares en los que se cumple, se necesita, y mas aun, es apropiado.
Sin embargo, considero apropiado tu comentario de prevencion para personas que no esten seguras si quieren hacer lo que quieren hacer.

¿Por qué? Por principios básicos de diseño POO, porque no utilizas el "patrón estratégico más importante de la POO" que es el Polimorfismo.

Disculpa, pero este punto si tengo que pensar que solo lo escribiste para demostrar que sabes terminos "fancy" jejeje... Me es dificil creer que no ves el polimorfismo en un ORM.

Recomendación: busca material en Google sobre "Liskov herencia de clases y principio de sustitución".

Gracias. Buscare para ver si es que he estado equivocado o para entender algun punto de los que hayas tratado de decirme ;) (quizas un poco de ironia aqui)

PD: hay un principio que dice "si me cambias de contexto, tengo que cambiar de solución"; si planteas algo, te responderemos en base a ese planteo, pero si luego nos dices "que tu contexto es otro", no pidas que la misma respuesta sirva para algo que ni siquiera nos lo presentas.

Lo se, lo siento, no pense que te ofenderia hacerte saber que lo que estaba haciendo era algo distinto a lo que pensaste. Sin embargo lo hice porque pense que el primer mensaje era de verdad con intenciones de ayudarme, entonces quise especificar bien que podia ser lo que estaba haciendo para seguir con el tema, aunke ya estaba resuelto.
Pido disculpas de nuevo, pero recordemos que no esta mal equivocarse en un foro, asi sea por culpa de alguien que no dio su verdadero contexto ;)...

Esto no es una competencia de "quién sabe más" y...

Ciertamente, te repito, mi intencion es compartir ideas contigo y con cualquier otra persona a la que le interese el tema. thats it.
Tambien, como precisamente creo que no es una competencia por ver quien sabe mas, no te dejo links de cosas que me imagino que ya sabes sino que trato de explicar lo que entiendo para obtener ideas al respecto. Estamos de acuerdo, no hay que ver quien sabe mas, luego no tienes que salirme con comentarios un poco aislados de patrones ;) (so you can feel at home)

tú no estás en evidencia por "no saber" (no hace falta que te defiendas)

Exactamente igual para ti, amigo.

pero respeta el tiempo de los demás que buscan darte una mano, por lo menos habla claro y sé franco.

Y en esto no tengo nada que responder. Gracias por estar aqui y por ofrecer este buen servicio. Aparte del hecho de que no estoy de acuerdo con la arrogancia con la que me has hablado, me parece que haces bien estando aqui y ayudando con las preguntas que surgen en otras personas. Estare a la orden si en algun momento llegas tu a tener una duda en algun otro ambito y yo puedo ayudarte o devolverte el favor.

Gracias de nuevo, y disculpa si este post suena un poco flamer de mi parte. Todo forma parte de esta "(no)competencia" jeje ;)

[enriqueplace]

Que manera de hacernos perder el tiempo.

Es más productivo abandonar el tema que responder (no voy a entrar en una discusión etérea).

[Volrath]

De nuevo con otra falta de respeto, sin embargo me alegra que hayas leido lo que escribi.

Una ultima recomendacion: tienes mucho para dar, solo tienes que cambiar tu actitud hacia los demas.

Saludos!