[SOLUCIONADO] PHP OO Duda con funcionamiento y organización de Traits

[guardarmicorreo]

Leyendo el manual de PHP con sus ejemplos, no me ha quedado claro lo siguiente:

¿Para que dos clases de PHP puedan compartir métodos y atributos mediante Traits deben "use" el mismo Trait?

Respecto a la organización de los Traits en el sistema de archivos y carpetas:

¿Dónde es mejor alojar los Traits, en un documento a parte de las clases, en el mismo documento de las clases, en el documento de la clase que más utilice Traits?

Estoy haciendo desde cero un sistema captcha y decidí hacerlo pero utilizando Traits y de ahí estas dudas.

Saludos! :)

[pateketrueke]

¿Para que dos clases de PHP puedan compartir métodos y atributos mediante Traits deben "use" el mismo Trait?

Los traits te permiten reutilizar piezas de código fácilmente.

¿Dónde es mejor alojar los Traits, en un documento a parte de las clases, en el mismo documento de las clases, en el documento de la clase que más utilice Traits?

Deberían ubicarse de manera que esto pueda llevarse a cabo sin afectar código adicional.

Es decir, al igual que las clases deben estar en su propio archivo, etc.

[Italico76]

Concuerdo deben estar solitos en sus propios archivos porque justamente son reutilizables por varias clases y es el criterio para las primeras.

Se pueden usar Namespace para unificar logicamente con las clases relacionadas.

[guardarmicorreo]

Muchas gracias a ambos. Solo hay una cosa, respecto a mi primera pregunta no me quedó clara la respuesta.

Estoy probando lo siguiente en cuatro archivos en el mismo directorio:

clase A (archivo ca.php)

Código PHP:

class A{
    public function methodA(){
        echo "A";
    }
}
 

trait B (archivo trait.php)

Código PHP:

require_once 'ca.php';
 
trait B{
    public function methodA(){}
}
 

clase C (archivo cc.php)

Código PHP:

require_once 'trait.php';
 
class C{
    use B;
}
 

archivo action.php (simplemente para instanciar la clase C)

Código PHP:

require_once 'cc.php';
 
$o=new C();
$o->methodA();
 

Y no imprime "A".

En cambio si coloco todo en el mismo archivo

Código PHP:

class A{
    public function methodA(){
        echo "A";
    }
}
 
trait B{
    public function methodA(){}
}
 
class C{
    use B;
}
 
$o=new C();
$o->methodA();
 

Sí imprime "A"

¿Por qué sucede esto?

En los ejemplos del manual lo explican como si todo fuera en el mismo archivo, pero ¿cómo utilizar los traits cuando los ubicamos en archivos distintos?

Un saludo! :D

[guardarmicorreo]

Me equivoqué en mi último post. No imprime "A" aunque todo esté en el mismo documento, no me fijé que C "extends" A, entonces metí la pata.

Entendiendo esto ¿quiere decir que a la hora de programar orientado a objetos los Traits son clases que no se pueden instanciar como las abstractas y que tienen código funcional para ser "use" por otras clases?

Entonces entendí los Traits al revés, creía que los Traits eran como las interfaces pero que permitían usar los métodos entre todas las clases que "use" el mismo Trait.

Por favor, que alguien me lo aclare.

[Italico76]

Pues a mi con PHP 5.4.26 no me imprime nada ni todo junto y con error_reporting(-1) no me da ningun error. Probe otro ejemplo del manual y si funciono.


A estos Traits no les veo mucho futuro...... no me convence usar herencia multiple en estos tiempos de composicion

Encontre un articulo interesante que deberias leer @guardarmicorreo

[guardarmicorreo]

Bueno, supongamos que los Traits solo sirven para generar code-smell :D

Y entonces ¿cómo resolver la herencia múltiple? No veo que proponga nada, simplemente criticar que se abusan de los Traits porque no se sabe programar.

[Italico76]

Iniciado por Italico76

A estos Traits no les veo mucho futuro...... no me convence usar herencia multiple en estos tiempos de composicion

El tema es que existen alternativas en la composicion de objetos...... y con muchas ventajas como menor acoplamiento y dinamicas

PHP va en contra de la corriente, montado en una ola pequeñita, la lo de los "mixin" que propone Ruby pero la tendencia hace tiempo es no mas herencia multiple primero porque genera muchos conflictos (que deben resolverse en tiempo de compilacion) y segundo porque ya existen patrones de diseño que resuelven esa necesidad.


Es posible el PHP Group este un poco temeroso de la fuerza que esta cojiendo Python o de un resurgimiento de Ruby, ambos ricos en caracteristicas y con algun tipo herencia multiple pero los mixin no son algo que la comunidad estuviera pidiendo a gritos.

[hhs]

Que tema tan interesante. se que llego tarde pero es para agregar comentarios adicionales

Iniciado por guardarmicorreo

Entendiendo esto ¿quiere decir que a la hora de programar orientado a objetos los Traits son clases que no se pueden instanciar como las abstractas y que tienen código funcional para ser "use" por otras clases?

Entonces entendí los Traits al revés, creía que los Traits eran como las interfaces pero que permitían usar los métodos entre todas las clases que "use" el mismo Trait.

Por favor, que alguien me lo aclare.

Se parecen pero son conceptos completamente diferentes, lo que tienen en común es que promueven la reutilización de código:

• Las clases abstractas son interfaces para sus clases hijas y promueven la reutilización de código mediante la herencia y polimorfismo.
• Las interfaces al separar el comportamiento de la implementación promueven la reutilización mediante polimorfismo.
• Los traits refactorizan el comportamiento sacándolo de la clase, así que promueven la reutilización como unidades primitivas de funcionalidad que pueden utilizar otra clases.

Generalmente se usan las interfaces para proveer funcionalidad entre clases que no tiene una relación, pero no es para lo que se hicieron las interfaces aun que el lenguaje permite usarlas de esa forma.

Iniciado por Italico76

A estos Traits no les veo mucho futuro...... no me convence usar herencia multiple en estos tiempos de composicion

Precisamente un objeto puede ser visto como la composición de unidades mas pequeñas de comportamiento, de tal forma que pueden ser reutilizables. Esta es la idea detrás de los traits y no implica la herencia múltiple. El detalle es que en php esto parece tener tintes de herencia múltiple por la forma en la que esta implementado y es que también pueden ser usados como mixin . Pero si los usas con el concepto que deben de tener no veo mayor problema

Iniciado por guardarmicorreo

Bueno, supongamos que los Traits solo sirven para generar code-smell :D

Y entonces ¿cómo resolver la herencia múltiple? No veo que proponga nada, simplemente criticar que se abusan de los Traits porque no se sabe programar.

Así es hasta cierto punto el articulo mas bien parece un resistencia al cambio. La realidad es que en muchos panoramas no la necesitas, Solo en caso que no tienes control para tener un intermediario que implemente las funcionalidad que necesitas y la composición no te sirve.
y si llegas a ese punto tal vez el trait se lo tuyo.

[dashtrash]

Iniciado por Italico76

El tema es que existen alternativas en la composicion de objetos...... y con muchas ventajas como menor acoplamiento y dinamicas

No es lo mismo.No estoy muy seguro de que las personas que manejan esta argumentación, hayan usado mucho la herencia multiple en c++, y luego hayan pasado , por ejemplo, a Java.

Hay muchos argumentos, pero sólo voy a dar uno:El argumento de la composición de objetos es igualmente aplicable a la herencia simple.Si eliminas cualquier tipo de herencia, seguirás teniendo composición.
Si hay algún tipo de ventaja en la herencia, la hay en la herencia múltiple.Si no la hay en la múltiple, no la hay en ninguna.

Por cierto, yo entiendo que los lenguajes quieran evolucionar y tal, y que haya competitividad entre los lenguajes a ver quién añade nosequé cosa nueva...personalmente, lo veo todo como puro marketing.Y no creo que los programadores , o los sistemas hechos con esos lenguajes, sean los beneficiados. En este punto, es interesante ver cómo lenguajes como javascript, con muuuy poquita evolución a lo largo de los años, ha encontrado nuevos paradigmas de programación sin llenar de "features" el lenguaje.

[guardarmicorreo]

:) creía que me había quedado claro, pero veo que no.

Italico76 dijo que los Traits se pueden evitar desacoplando en mayor medida las clases, cosa que creo que es discutible y que no tienen mucho que ver una cosa con la otra.

Pero en general entendí que los Traits, por muy útiles que sean, no están contemplados en el futuro de la mayoría de lenguajes porque es algo que lleva a crear código dañino a la vista (como el mío :D ).

Pero ahora llegais hhs y dashtrash y le dais un nuevo enfoque. Fascinante :D

vamos a ver si me entero sobre código

Esto sería la herencia simple en PHP

Código PHP:

<?php
 
abstract class A {
 
    public static function saymethodsA() {
        return get_class_methods('A');
    }
 
}
 
class B extends A {
 
    public function printmethods() {
        ?>
        <pre>
        <?php
        var_dump(parent::saymethodsA());
    }
 
}
 
B::printmethods();
/*
 * imprime
 * 
   array(1) {
    [0]=>
    string(11) "saymethodsA"
   }
 * 
 */
 

Esto es el uso de Traits para simular la herencia múltiple solucionando ciertos problemas que conlleva la herencia múltiple como tal.

Código PHP:

abstract class E {
 
    public static function saymethodsE() {
        return get_class_methods('C');
    }
 
}
 
Trait coreEF{
    public static function saymethods($class){
        return get_class_methods($class);
    }
}
 
class F{
    use coreEF;
}
 
?>
<pre>
<?php
var_dump(F::saymethods('A'), F::saymethods('B'), F::saymethods('E'), F::saymethods('F'));
 
/*
 * imprime
 */
//array(1) {
//  [0]=>
//  string(11) "saymethodsA"
//}
//array(2) {
//  [0]=>
//  string(12) "printmethods"
//  [1]=>
//  string(11) "saymethodsA"
//}
//array(1) {
//  [0]=>
//  string(11) "saymethodsE"
//}
//array(1) {
//  [0]=>
//  string(10) "saymethods"
//}
 

¿Cómo se podría resolver el problema de los Traits desacoplando las clases unas de otras?

(Entiendo desacoplar como la estrategia de componer/construir/escribir clases de manera que unas dependan de las otras lo menos posible)

A mi solo se me ocurren dos posibilidades y no estoy seguro de la segunda:

1) metiendo en clases funcionalidades que no guardan relación entre si, por lo tanto se estaría rompiendo lo que es el concepto de POO.

2) utilizando los namespaces de manera tal que dentro de las propias clases se utilicen otras clases.

EDITO:

hhs no me confundas más!! jaja que me costó mucho entender la gran enorme diferencia entre interfaz (algo raro que no entiendo su utilidad relevante) y el resto de código ejecutable y útil, como clases y traits :D

[dashtrash]

Iniciado por guardarmicorreo

¿Cómo se podría resolver el problema de los Traits desacoplando las clases unas de otras?

Y por qué querrías desacoplarlas? Como para mí los traits son herencia múltiple disfrazada, eso es equivalente a preguntarse cómo desacoplar una clase de su clase base.No quieres hacer eso.

Considero un sistema acoplado cuando existen dependencias entre clases, y no son completamente necesarias.
Ejemplo: una clase A que gestiona pedidos, que usa una clase B para enviar emails.Para gestionar un pedido, no es absolutamente necesario enviar un email. A su vez, mañana podríamos necesitar que, además de enviar un email, envíe un SMS o quién sabe qué.Lo que quieres es que la clase que sea, haga su trabajo, y exclusivamente su trabajo (aunque a nivel de negocio, la creacion de un pedido implique que se envie un email, a nivel de responsabilidad de código, la clase Pedido no debería enviar ningún email).
La programación orientada a eventos es una solución sencilla.Cuando un pedido se crea, lanza un evento de "Pedido creado", y alguien que está subscrito a ese evento, lanza un email.Pero las clases Pedido y Email no se conocen entre sí.
A eso es a lo que yo llamo un código desacoplado.
Si A hereda de B, A *es* un B.No tiene demasiado sentido desacoplar algo de sí mismo.

Por cierto, traits no son exactamente mixins.Los traits se especifican en tiempo de "compilacion".Un "mixin" puede crearse en tiempo de ejecución (véase javascript).

[hhs]

¿Cómo se podría resolver el problema de los Traits desacoplando las clases unas de otras?

(Entiendo desacoplar como la estrategia de componer/construir/escribir clases de manera que unas dependan de las otras lo menos posible)

Un Trait no pretende desacoplar las clases, ese es un tema que se resuelve de otras formas. El trait te sirve para reutilizar comportamiento colocándolo en otro sitio y que lo puedas utilizar en otras clases.
Una forma vulgar de verlos, seria como un copy paste de los métodos que hacen lo mismo y están distribuidos en diferentes clases.

hhs no me confundas más!! jaja que me costó mucho entender la gran enorme diferencia entre interfaz (algo raro que no entiendo su utilidad relevante) y el resto de código ejecutable y útil, como clases y traits :D

Los conceptos relacionados con la POO son a veces confusos por que hay una tendencia a pensar mas en las clases que en los objetos y hay que recordar que construimos sistemas orientados a objetos no a clases.

Para finalizar espero haber aclarado un poco el panorama y espero que pruebes por ti mismo si tiene alguna utilidad para ti.

[guardarmicorreo]

Muchas gracias a ambos, dashtrash y hhs. Me pondré a trabajar sobre el código para poder ver todo lo que me habéis dicho y tratar de sacar alguna conclusión en claro.

Un saludo! :)

[Italico76]

Iniciado por guardarmicorreo

:)
Italico76 dijo que los Traits se pueden evitar desacoplando en mayor medida las clases, cosa que creo que es discutible y que no tienen mucho que ver una cosa con la otra.

Ojo que nunca dije tal cosa! todo lo contrario, el uso de Traits puede generar mayores dependencias que usar objetos en Composicion

Yo usaria Traits solo cuando quiero reutilizar codigo, no sea aplicable la herencia (clases poco relacionadas) pero siempre va a ser mas rigido que usar objetos porque las dependencias en el caso de los Traits son tratadas en "tiempo de compilacion" mientras que si usas "objetos" (no clases) en composición es en "runtieme"