Comentarios en: ¡Extends es una mierda! ¿No te habías enterado?

Por: Alejandro Pérez (@alejperez)

Alejandro Pérez (@alejperez) — Fri, 29 Jun 2012 14:35:09 +0000

Como soy bastante friki, he probado ese mismo ejemplo en Smalltalk, en concreto en Pharo, http://www.pharo-project.org , y “funciona bien”…

ListaAuditable Contenidos: pepe, Juan, Luis,

Notificación Auditores: pepe, Juan, Luis,

Es decir, al llamar al insertar de la clase padre no “rebota” al insertar de la clase auditada…

Supongo que como Smalltalk sólo existe desde los 70 no han podido “copiarlo bien”…

Saludos

Por: ¡ Extends es una mierda ! Composición y delegación « Te lo dije …

¡ Extends es una mierda ! Composición y delegación « Te lo dije … — Mon, 20 Feb 2012 09:31:41 +0000

[...] o el “Decorator” entre otros. Antes de nada voy a resumir lo contado hasta ahora. En el primer post vimos cómo usar la herencia de implementación de forma “ingenua” nos podía meter en [...]

Por: ¡Extends es una mierda! Diseñando para la herencia « Te lo dije …

¡Extends es una mierda! Diseñando para la herencia « Te lo dije … — Mon, 13 Feb 2012 09:59:46 +0000

[...] Comentarios « ¡Extends es una mierda! ¿No te habías enterado? [...]

Por: Enrique Amodeo

Enrique Amodeo — Sun, 12 Feb 2012 22:01:51 +0000

Yo lo que cuento es en base a mi experiencia, y en mi experiencia “extends” no me lleva a un buen diseño y he terminado por dejar de usarlo. Lo curioso que ahora que no lo uso, no lo echo de menos.
Entiendo que tu tengas otro punto de vista, pero no termino de entender cuales son tus argumentos. Bueno, a ver si en el próximo me explico algo mejor, que me parece que han quedado algunos puntos en el aire, y hacemos el debate más productivo.

Por: Enrique Amodeo

Enrique Amodeo — Sun, 12 Feb 2012 21:33:04 +0000

Cierto, cierto. Tienes razón, lo más peligroso no es el “extends”, sino los equipos que no hablan entre si.

Por: Javier Neira (@jneira)

Javier Neira (@jneira) — Sun, 12 Feb 2012 20:43:47 +0000

Mmm no me refiero al ejemplo concreto de la lista sino en que la situacion que has descrito las clase esta siendo usada desde fuera de su hogar original (o sea esta expuesta, conscientemente o no en el api publica de ese “hogar”) y es usada por un programador y modificada posteriormente por otro sin que haya comunicacion entre ellos. Hablo pues del contexto no tecnico del ejemplo, que es lo que en mi opinion hace realmente peligrosa la herencia (pero tambien otras tecnicas de uso entre unidades de software).

Eso se une al problema de que en ese uso se dependa de la implementacion interna y se una en sagrado matrimonio a dos fragmentos de codigo que viven en paises muy lejanos, lo que haga que cualquier pequeño cambio destroce la relacion. ¿Quiere decir eso que el matrimonio es peligroso en todo caso? Pues tal vez en muchos si pero no en todos.
Hay clases (o modulos o lo que sea) que estan hechas las unas para las otras desde su nacimiento.

Dicho esto tengo que admitir tambien que hay tecnicas que tienden mas que otras estrechar el acoplamiento y a crear dependencias de implementacion: la herencia hace visibles mas miembros de la clase y permite usarlos de manera mas comoda que con otros usos (p.e la delegacion que es su sustituto natural). Tambien hay que admitir que se ha abusado alegremente de la herencia (en java sobre todo) y yo he sido el primero en sufrirla (y lo sigo haciendo) con librerias como struts.

Sin embargo para mi lo esencial del problema esta en la organizacion del trabajo del equipo (o de tu propio trabajo si hablamos de un unico programador) y en crear dependencias de la implementacion interna entre unidades de codigo que no tienen que tenerlas.

Por: jmarranz

jmarranz — Sun, 12 Feb 2012 17:56:16 +0000

A mi personalmente me da bastante igual lo que diga el guru de turno, después de cientos y cientos y cientos de herencias de implementación en C++ y Java, mi opinión es la contraria, prescindir de la herencia de implementación ESO SI que es para mi una verdadera pesadilla, y no, no estoy pensando en el típico ejemplo de un nivel de herencia de una clase con un par de métodos, en donde las cosas no cambian prácticamente nada si se usa composición, estoy pensando en cosas como esta:

http://docs.oracle.com/javase/1.4.2/docs/api/javax/swing/JCheckBox.html

Sólo imaginar ese código como composición me pondría los pelos de punta.

(aunque con esto no quiero decir que AWT/Swing sea la mejor API diseñada del mundo ni mucho menos).

Aunque no se que pasa pero la gente que hace software complejo de narices es que no aprende de los “gurus” y se empeña una y otra vez en usar herencia de implementación para resolver problemas reales:

http://docs.oracle.com/javafx/2.0/api/javafx/scene/control/RadioButton.html

Aunque puestos a elegir gurus prefiero a Cedric Beust

“We all know that inheritance can be abused, but isn’t it so for every feature of every language on the planet? Instead of giving in to simple sensationalism, how about studying the pros and cons of inheritance and trying to educate your readers objectively?”

http://beust.com/weblog2/archives/000004.html

Pero en fin que cada uno piense lo que quiera pero en mi opinión hay que tener mucho cuidado cuando uno mismo se pone piedras en el camino.

Por: Enrique Amodeo

Enrique Amodeo — Sun, 12 Feb 2012 17:22:50 +0000

No se porqué os lo tomais como un ataque a JAVA. La herencia de implementación es una mierda y no importa si es con JAVA o con Ruby o con JavaScript o con C++. De hecho el problema se detectó en los tiempos del C++, donde se había usado intensivamente la herencia de implementación como mecanismo de reutilización en las MFC de Windows. No se si alguien se acuerda de esos tiempos, pero a mi me pilló de estudiante y aun tengo pesadillas….
La herencia de implementación no es nuclear a la OO, es nuclear a la orientación a clases, que son dos cosas diferentes. Y da igual, aunque fuera nuclear a la OO original, ¿y qué? No veo como ayuda eso a la herencia de implementación como técnica.
Lo que yo tengo entendido que dijo James Gosling es que si tuviera que volver a “inventar” JAVA, no le pondría “clases”, tras las caras de estupefacción de los asistentes, aclaró que el verdadero problema era el “extends”. De todas formas esto es apocrifo, no he conseguido encontrar ninguna cita directa de él sobre esto (pero sí de asistentes que dijeron que el había dicho…). No es importante, da igual lo que dijera James Gosling, Martin Fowler o el tio Bob, no usaré el argumento de autoridad. Lo importante es que “extends” es realmente peligroso, y prefiero no usar nitroglicerina si puedo usar explosivo plástico, que es más seguro y más potente.

Por: jmarranz

jmarranz — Sun, 12 Feb 2012 17:02:27 +0000

“Quizás debieras echar un vistazo al Collection Framework de Java y luego nos cuentas las líneas de código que habrías acabado tirando sin extends…”

Plenamente de acuerdo Albert J. Reily, imagina Swing y en general tu razonamiento es aplicable a cualquier árbol de derivación hecho con sentido común, ya que hablamos en términos de “mierda”, me imagino lo que sale al convertir a composición una herencia de implementación de tres clases (tres niveles): seguramente una mierda.

Varias cosas:

No me creo que James Gosling dijera exactamente eso, lo que si me creo es que dijera algo así como que hay un excesivo número de clases públicas en el core de Java en vez de ser interfaces y en eso estoy totalmente de acuerdo, el framework de colecciones a base de interface/implementación es un ejemplo de una API bien hecha en ese sentido y podría ser mejor aún con algún tipo de sistema de factoría.

El concepto de extends es MUY anterior a Java y es NUCLEAR de la orientación a objetos, sin herencia de implementación la OOP se reduce prácticamente a NADA.

“la herencia de implementación, que es más peligrosa que una caja de bombas”

Cierto, pero la solución NO debería ser “como es peligrosa es mierda”

Es como decir

“Como pusimos al niño a los controles de la central nuclear y la lió la energía nuclear es mala, mejor generar energía pedaleando”

“Como le dimos al niño un bisturí la cirugía es mala y la lió, mejor con hierbas”

La solución es decirle al junior, niño no toques si no sabes lo que estás haciendo, por muy buena y encapsulada que sea tu API jamás podrás impedir que un uso indebido de la misma.

Hechad un vistazo al código fuente de vuestro framework/herramienta favorita, Tomcat, Hibernate, Spring, GlassFish, las propias tripas del JDK… etc y verás herencias de implementación por un tubo… afortunadamente.

Lo siento en mi opinión esta moda de que la herencia es mala lo que está llevando es que una generación de programadores estén haciendo de nuevo código C por mucho Java, Scala o el lenguaje “moderno” de turno que usen.

Por: Enrique Amodeo

Enrique Amodeo — Sun, 12 Feb 2012 16:50:12 +0000

El Collection Framework de JAVA lo conozco bastante bien. Como he dicho antes esto es un mero ejemplo, quería un ejemplo sencillo que no confundiera el mensaje, y cómo dije también antes, a veces cuando modelas negocio es bueno encapsular los tipos primitivos y del sistema. Es mejor cosas como CatalogoDeProductos, UltimosMovimientos o Empleados a Collection, List o Set.
Veo que algunos no parais de repetir lo mismo: “es que extends hay que saber usarlo”, “es que extends es muy útil en algunas circunstancias”, “es que quieres usar la misma herramienta para todos los casos”, etc… De momento no he visto ningún caso concreto en el que la herencia de implementación sea la mejor técnica a aplicar. Si alguno tiene un ejemplo concreto que lo publique en su blog, y que me lo diga, para poder enlazarlo desde el mio. Al fin y al cabo el “goto” también era muy “útil”, e incluso se podía usar “bien”.
P.S. No, no he leido recientemente “Favor composition over inheritance”, estas ideas empecé a verlas en el año 2000 cuando me leí el GoF, y unos pocos años después leí algunos posts confirmándolo