[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.