Nueva Encuesta de Embarcadero

[[nlsgarcia]]

Al González,

Empezado por Al González

...que el compilador de Delphi permita redefinición de clases (herencia insertada)...

Pregunto:

1- ¿Que es Herencia Insertada?

2- ¿No sería mejor Herencia Múltiple en Delphi?

Saludos,

Nelson.

[[Al González]]

Empezado por nlsgarcia

1- ¿Que es Herencia Insertada?

Hola Nelson.

Aunque es algo teórico en Delphi todavía, básicamente consiste en que, teniendo una jerarquía de clases tal como:

      ...
       |
       TA
       |
   ---------
   |       |
   TB      TC
   |       |
 -----   -----
 |   |   |   |
... ... ... ...

puedas derivar e "insertar" una clase TA1 (o "redefinir" la clase TA), agregándole más campos, métodos y todo lo que puede tener una clase normal (cosa que no satisfacen los ayudantes de clases). De tal manera que la nueva clase quedaría en el esquema así:

      ...
       |
       TA
       |
      TA1 (clase "insertada")
       |
   ---------
   |       |
   TB      TC
   |       |
 -----   -----
 |   |   |   |
... ... ... ...

Y todo, claro, sin necesidad de modificar el código fuente de las clases ya existentes.

Aunque no lo he revisado, recuerdo que Román comentaba hace tiempo que esta característica se encuentra presente en JavaScript.

Un saludo.

[[nlsgarcia]]

Al González,

Empezado por Al González

...Aunque es algo teórico en Delphi...básicamente consiste en que, teniendo una jerarquía de clases...puedas derivar e "insertar" una clase...sin necesidad de modificar el código fuente de las clases ya existentes...

Gracias por la información

Pregunto : ¿Y el uso de Herencia Múltiple en Delphi no sería también una opción a considerar?

Saludos,

Nelson.

[[Al González]]

Empezado por nlsgarcia

¿Y el uso de Herencia Múltiple en Delphi no sería también una opción a considerar?

Creo que la herencia múltiple debe ser considerada también, aunque tratando de la mejor forma posible el problema del diamante.

Saludos.

[[nlsgarcia]]

Al González,

Empezado por Al González

...Creo que la herencia múltiple debe ser considerada también, aunque tratando de la mejor forma posible el problema del diamante...

Empezado por wikipedia

...Hay debate sobre si la herencia múltiple puede ser implementada de forma simple y sin ambigüedad. Con frecuencia es criticada por su aumentada complejidad y su ambigüedad, así como los problemas de versiones y mantenimiento que puede causar (a menudo resumido como el problema del diamante)...

Tomado de: Herencia múltiple

Supongo que por estos problemas de ambigüedad, Delphi y C# utilizan interfaces como una forma alternativa de herencia múltiple.

Saludos,

Nelson.

[[Al González]]

Empezado por nlsgarcia

Supongo que por estos problemas de ambigüedad, Delphi y C# utilizan interfaces como una forma alternativa de herencia múltiple.

Sí, y es que el uso de interfaces es limpio y suficiente para muchos casos.

Pero me extraña ver tantas disertaciones sobre herencia múltiple con todos los contras que tiene, y casi ninguna mención a la redefinición de clases (o "herencia insertada"), en lenguajes populares como Delphi, C#, etc.

Por otra parte, mamcx, he notado que haces mucho hincapié en las dificultades para reutilizar código cuando éste se encuentra en métodos de clases y sólo necesitamos uno de esos métodos o parte de él, y no toda la jerarquía de clases que arrastra. Me pregunto si habrás mirado con detenimiento en GH Freebrary, donde hay más de 40 clases y la mayor parte del código fuente que éstas emplean se encuentra separado en cientos de funciones independientes. Así el programador tiene la libertad de usar una clase de esta biblioteca o solamente las funciones que necesita, según sea su objetivo. Y es que yo me tomo muy en serio lo del aprovechamiento y reutilización del código, sin caer en aquella tristemente exitosa trampa conceptual de que "encapsular" es meter todo el código fuente en los métodos.

Un saludo.

[mamcx]

No conozco GH Freebrary, llevo un rato desconectado de trabajo serio en Delphi (). Por lo que describes, estas empleando el concepto de "Composicion sobre herencia", que fue desarrollado precisamente entre los lenguajes OO, tal como explica el link de wikipedia. Me parece que eventualmente todo programador experimentado en OO llega, aun sin darse cuenta y de forma informal, a la idea puramente porque es una forma mas sana de trabajar.

[mamcx]

Empezado por Al González

Creo que la herencia múltiple debe ser considerada también, aunque tratando de la mejor forma posible el problema del diamante.

Saludos.

Hacer herencia multiple es multiplicar el problema de la herencia. Es por eso que es mejor:

Composicion sobre herencia.

Luego de muchos años de hacer OO, es claro que la herencia es la forma *errada* de lograr la reutilizacion de codigo:

http://raganwald.com/2014/03/31/clas...t-do-that.html

http://javarevisited.blogspot.sg/201...ps-design.html

No solo porque arrastran todo el edificio cuando solo necesito prestado un martillo, sino porque hacen rigido el esquema del código y complican jodidamente el poder reusar el codigo.

Hay 2 formas que serian mucho mejor, pero seria complicado retro-corregir un lenguaje como Delphi/Java.

El metodo mas practico (desde el punto de vista del acostumbrado a OO) y parecido es el de GO:

http://www.onebigfluke.com/2014/04/g...-behavior.html

El segundo son los multi-metodos:

http://nice.sourceforge.net/visitor.html (Implementado en NICE, un lenguaje parecido a Java)

Y en Julia, que es mas funcional:

http://julia.readthedocs.org/en/latest/manual/methods/

----

El asunto del porque la herencia es la solucion herrada (no siempre, pero muchas veces) es que es una violacion de la idea de

http://users.ece.utexas.edu/~adnan/pike.html

Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

Y

Plano es mejor que anidado
---Zen de Python

Un ejemplo de se muestra en http://www.onebigfluke.com/2014/04/g...-behavior.html es el de hacer una app que sirva como un servidor web.

Como se soluciona tipicamente? Pues tienes que tener un IndyHTTP o un SinapseHTTP, heredar de eso, y implementar el metodo(s) que REALMENTE es necesario, pero ademas, probablemente reimplementar un monton de otros. Y como se arrastra TODA la jerarquia, no siempre es claro que hay que reimplementar (no saben cuantas veces se ignora reimplementar metodos como el de hash, igualdad y otros).

En cambio, tomando a GO por ejemplo, si quieres que tu codigo sea un servidor web (ilustrando con un ejemplo bastardizado de pascal):

Código Delphi [-]
procedure Clientes.ServeHTTP(w as http.ResponseWriter; var r as http.Request)
begin
       r.write("El cliente esta feliz!");
end;

Este codigo: Declara que conforma con la interface de un servidor web, define su implementacion y se encarga de pasar los param de request/response. Noten que esta totalmente desacoplado, es testeable, no hay que "montarlo" sobre puertos, Es irrelevante el porque rayos mi clase de manejos de clientes de un momento a otro puede ser un servidor web, es totalmente compatible con cualquier codigo que acepte esa interface. Un monton de cosas, y a la vez: No hay herencia, no se traen tropocientos metodos inutiles, no trae codigo inutil, no importa si la implementacion de sockets es Synapse o Indy o lo que sea, no importa que Clientes no es una libreria exclusiva de servidores web...

No hay que crear una subclase. No hay que reimplementar nada. No hay que pensar cual de los tropocientos metodos y campos son o no importante. No se puede, por error o brutalidad, llamar a un metodo o campo del padre que no tiene importancia, es inutil o hace un desastre.

Y se puede hacer herencia, algunas veces...

P.D: Una forma de lograr lo que se quiere de la herencia multiple, sin traer sus problemas y promover el desacoople es permite re-abrir funcionalidad de una clase, una forma de como se ve esto:

https://developer.apple.com/library/...xtensions.html

Pascal bastardizado:

Código Delphi [-]

reopen TControl 
    constructor (center as TPoint, size as TSize):
    begin
    end;

    function print():String
    begin
    end;

El cambio es localizado, no hay herencia (plus), se pude jalar lo necesario de otras clases(s)/funciones (incluso de varias) y no se "contamina" toda la clase de forma universal.