Herencia múltiple en C#

[Hans]

Nunca la he necesitado pero hay una cosita que me gustaría hacer y no lo veo posible sin esto. He leído algo acerca de interfaces pero creo que eso sólo permite definir métodos para futuras clases, no implementarlo (luego hay que hacerlo en cada clase), así que tampoco me sirve.

[Vicente]

No se puede hacer herencia múltiple en C#. Como dices se pueden implementar varias interfaces.

Que quieres hacer?

[Hans]

Tengo clases que heredan de otras pero quería que todas heradaran a parte de una clase común para que todas usaran un par de métodos que no tienen las clases que heredan ahora mismo. Luego lo pensaba meter todo en una lista de esa clase y utilizar esas funciones en todas las que yo quisiera a la vez sin tener que preocuparme de lo que era. Principalmente era para hacer desactivaciones/activaciones por sectores de objetos cargados en memoria pero en desuso y que volverán a usarse en breve para así no necesitar tener que cargar y descargar nada nunca.

Pero ya he encontrado otra manera de hacerlo y funciona bastante bien, aunque la herencia múltiple hubiera sido mucho más limpio. ¿Alguna razón para no soportarla?

[WaaghMan]

Que suele crear más problemas de los que soluciona por la posibilidad de heredar de la misma clase desde dos padres distintos. A veces es un poco putada, porque las interfaces solucionan parcialmente el problema (por ejemplo te permiten lo que estás diciendo, pero probablemente te tocaría repetir código).

En tu caso buscaría una manera de hacer que realmente heredasen de una clase común, pero en la misma jerarquía, si tiene sentido (la relación "es un"), y si no, tiraría de un interfaz (que se entiende más como un "puede hacer esto").

[Vicente]

Lo que dices parece así explicado un ejemplo de libro de una interfaz: un montón de objetos que no tienen nada que ver pero que tienen cierta funcionalidad común (IActivable o algo así).

Y sobre porque no se soporta en mi opinión es porque añade nuevos casos al proceso más complicado de C#: resolver a que método se llama. Los equipos de C# y del CLR no añaden nada al lenguaje a menos que aporte mucho en relación a lo que cuesta de implementar y mantener, y esto no está en la lista de cosas que se plantean ni de lejos :S

[Topper]

Si realmente no te resulta un engorro (mucho cambio en el código), podrías crearte una clase abstracta y utilizarla como base de todas las demás. Añades esos dos métodos comunes que comentas con la funcionalidad necesaria y a correr. A posteriori siempre puedes implementar las interfaces que sean necesarias.

Saludos,