![]() |
herencia multiple en php5 ¿Alguien conoce algun "truco" para usar la herencia multiple en php5? Gracias de antemano paloclanweb |
No soy el gurú de objetos, pero Java, hace más de 10 años que trabaja con objetos y no acepta herencia múltiple. Por algo será no? Una pregunta... PHP5, no podés hacer una interface como en java?, es una forma que se me ocurre. SALUDOS! |
|
si, php sigue casi la misma filosofia de JAVA, asi k si sabeis JAVA, pos podes hacer lo mismo, usa una interface....... |
quien dijo que java no acepta herencia multiple?? es una broma? |
echale un ojo a este link http://www.desarrolloweb.com/articulos/2026.php |
Gracias a todos...realmente php 5 no permite herencia multiple ...la solucion es utilizar interfaces Saludos |
SiR. Carajodida: Java no utiliza herencia multiple (fijate en cualquier manual, tutorial, etc). Lo que se utiliza es Interfaces. Igual PHP5. |
Cita:
...pero C++, hace más de 15 años que trabaja con objetos y sí acepta herencia múltiple. ¿Por algo será no? Y ya no te digo lenguajes más antiguos... Qué manía estos de Java, de decir que si algo existe es que es usado. Si no quieres herencia múltiple, no la uses. Pero mejor tenerla que no poder usarla, ¿verdad? paloclanweb, ánimo con tu uso de la herencia múltiple, si es que encuentras la manera de hacerlo funcionar (aunque lo dudo). |
Cita:
Por ejemplo, C++ tiene interfaces (clases abstractas puras que se llaman en realidad) y herencia múltiple y se usan para cosas diferentes. |
Por lo que he visto en varios lenguajes, la discusión legítima no es "si se puede hacer o no". En muchos casos no se implementa (como en Java, PHP, etc) porque usarla es un posible camino al desastre. Verdaderamente no es problema técnico, o de evolución, es un problema de criterios de diseño "OO". De todas formas siempre hay una puerta trasera: hacer "herencia múltiple" a través de interfaces; pero el sentido es distinto a hacerlo con clases. Las herencias de clases definen el "que son" y las interfaces agrupan clases que definen el "que hacen". Y finalmente, las interfaces permiten pasar del estilo de diseño "orientado a la implementación" a uno "orientado a la interfaz", donde todas las clases acceden a servicios a través de interfaces que son implementadas por clases concretas. Y al no depender de clases concretas (solo de entidades abstractas) nuestro diseño será más reutilizable que el anterior. Al final de cuentas, todo es una discusión de diseño OO ;-) |
Me parece que se está transformando en una discusión filosófica y lo importante sería PHP5 no implementa herencia multiple. Porque sino vamos a terminar hablando de SmallTalk :) SALUDOS. PD: MaxExtreme, my buena respuesta, más allá que estabas ironizando también con mi mensaje. PD2: Dejo otra reflexión, los desarrollos en JAVA, no funcionan tan bien en Windows, por algo será no? jejejeje |
Cita:
Java no lo hace pora poder simplificar un poco el modelo de objetos que tiene. Y en realidad Java implementa una pseudo herencia múltiple, con Interfaces. Saludos |
perdon pero no entiendo, en java nose puede hacer esto? Código: public class A { |
no, eso es un arbol de herencia. Para que fuese herencia multiple deberia ser algo asi: public class A {//...} public class B {//...} public class C {//...} public class D {//...} public class E extends A,B,C,D{//..} Java esto no lo permite. |
Cita:
El comité C++ salió allá por el 1990, y se empezó a implementar después. Pero el primer estándar verdadero ISO salió en 1998. Luego otro en 2003, y por último saldrá otro en el 2010. Java no lo hace porque no lo han visto esencial, por ahora, pero puede que lo añadan en un futuro. Java no para de cambiar. Lo cual no quiere decir que no deban implementar la herencia múltiple, que es MUY útil. |
Cita:
Pero tampoco conduzcas, no sea que te estrelles, o no salgas a la calle, que hay bacterias. ;) Las cosas como son: Es mejor tener que no tener, que sobre, que no que falte. Al menos, es mi punto de vista. Como Java soporte algún día la herencia múltiple, voy a reirme mucho xD Yo no suelo usar herencia múltiple, pero QUIERO que esté abierta la posibilidad. La excusa de "no está porque es un desastre" no es válida. Si existe la herencia múltiple es porque hubo gente que la vió útil. Por otro lado, C++ soporta "interfaces", que no son más que clases abstractas puras en realidad, así que existen las dos opciones. En C también puedes implementar interfaces. No son más que listas enlazadas que contienen estructuras que indiquen la dirección de memoria de cada función, los parámetros y el tipo de retorno (por poner un ejemplo). Se usa bastante cuando se trabaja con DLLs y plugins. Es código sucio, pero como en Java, no es más que "trucar" el asunto :P |
Cita:
En C++ se implemente así: Código: class ClientSide;Es una forma de programación muy útil si se sabe controlar. Si no sabes bien las reglas de la herencia múltiple (mucho más complejas que la de la simple, debido a la cantidad de "peros" y "qué-pasa-sí", constructores, destructores, ...) es un CAOS. |
Cita:
En teoría deberían funcionar igual, ¿no? Ups, no, depende de la máquina virtual y de los cafés que se dejaron de tomar los de GNU/Linux/Microsoft/Sun cuando trataban de implementar todo el J2XX. |
aa ahora entiendo, siempre entendi que herencia multiple era eso, pero en mi opinion no estaría bien eso, es como si una clase tuviera varios padres y eso no tiene sentido... nose, es mi humilde opinion, soy newbie en java :P |
Eso es hacer "múltiples herencias", no "herencia múltiple". ;-) La herencia múltiple sería: class C extends A,B{ } Donde la clase C hereda atributos y/o métodos de dos clases o más. Por ejemplo, la clase "HombreLobo" puede heredar de la clase "Hombre" y de la clase "Lobo", pero el problema es que se pueden hacer tantas combinaciones que es difícil de seguir y mantener un diseño de este tipo. Por eso muchos lenguajes no la implementan, no por un tema técnico, solo por un tema de salvaguardar la integridad del diseño. Los problemas más comunes son las "colisiones de nombres" y la "herencia repetida". Y ya que estamos, comento: en las guías de diseño recomiendan que para una buena jerarquía de herencia: - Deben tener no más de 7 (+-2) niveles - Las jerarquías "gordas y bajas" son síntoma de "poca especialización" - Las jerarquías "altas y flacas" son síntoma de "excesiva especialización". El tema es no abusar de la herramienta. |
en que basas tu opinión SIR? |
Cita:
No explico que situaciones, porque son problemas tecnicos muy especificas de una apliciacion. |
Cita:
Por ejemplo, yo uso herencia múltiple en muchos proyectos, tantos como haga una clase que no tenga que ser copiable. Defines una clase base que no permita su propia copia. Luego, de ahí heredas para que la hija adquiera ese comportamiento. Por ejemplo, defino una clase "ServidorFTP". No tiene sentido copiar la clase de un servidor FTP, por tanto, le define así: Código: class ServidorFTP : public Servidor, private NoCopiable;La librería Boost ya lo implementa. La clase "Noncopyable" sirve para eso. |
Cita:
Lo extraño asusta, pero no por ello es malo. |
Cita:
Y bueno, no opino lo mismo. Será el programador el que tenga que salvaguardar el proyecto, no el lenguaje. Por esa regla de tres, programemos en un Basic. Los problemas se pueden evitar, si se sabe hacer. Pero hay que aprender claro. En verdad, lo que ocurre es que para usar herencia múltiple hay que pensar bien las cosas antes de escribir nada, porque luego no hay vuelta a atrás. En cambio, con la simple, la gente lo ve como algo "más o menos fácil", y aún así, como no diseñes bien la aplicación, la has fastidiado. Los problemas más complejos vienen en el seguimiento del código, entender qué se está ejecutando antes y qué después, el seguimiento de la memoria, los punteros, que van y vienen entre clases y hay que reservar y liberar correctamente, no tener objetos duplicados, no perder rendimiento, etc. |
Sobre el lenguaje, todos tienes reglas distintas y distintas formas de atacar los problemas. Siempre existen limitaciones técnicas y no-técnicas, por eso optamos por uno u otro lenguaje. Con respecto al tema de "herencia múltiple", no es una sugerencia personal, lo dicen los grandes autores de grandes libros ;-) |
... tampoco bueno ... por eso es bueno leer, adquirir conocimiento, razonar, cuestionar, acumular experiencia para luego poder decidir por nosotros mismos. Conozco pocos programadores que leen o estudian materiales sobre diseño, principios y guías sobre Orientación a Objetos. Programar orientado a objetos es fácil, hacer un sistema reutilizable y con bajo costo de mantenimiento, difícil (todo un arte, diría). |
Cita:
No leamos sólo a los autores que nos interesan :) Por otra parte, muchos grandes programadores que no salen a la luz con libros, que trabajan detrás del escenario, programando fundamentalmente compiladores y sistemas operativos, tienen mucho que decir, y seguramente puedan opinar mejor ellos que un miembro del comité de estandarización de "X" lenguaje. Pero en la vida todo depende de la situación, no de la capacidad de las personas ;) |
Cita:
Conozco a muchos programadores, pero pocos lo son. Muchos se autoproclaman programadores de tal lenguaje, tecnología, metodología, paradigma (no sólo POO)... y no lo son ni de lejos. Hoy en día ser programador es muy fácil, hay críos de 10 años que programan. Por tanto, son "programadores". En cambio, encontrar personas que lleven o hayan llevado el tema de un kernel, de una aplicación ofimática, de un engine3d o proyectos de similar importancia en otras categorías, casi imposible si no les buscas expresamente. Supongo que ocurre en cualquier materia de la vida, pero en la programación, ha sido tan simplificada hoy en día (sobre todo con la aparición del dios-VB6), que parece que ser programador es ser tonto, puesto que te comparan con niños de 10 años. Lógico. Es como si ahora los niños de 10 años saben integrar porque usan Derive o Mathlab. |
| La zona horaria es GMT -6. Ahora son las 02:28. |
Desarrollado por vBulletin® Versión 3.8.7
Derechos de Autor ©2000 - 2026, Jelsoft Enterprises Ltd.