La herencia de clases es el mal

Muchas familias se han roto o distanciado por culpa de una herencia. Y, como en la vida real, en programación la herencia puede ser el mal absoluto.

La herencia de clases es una idea fantástica. Puedes coger una clase y extenderla a través de la herencia para crear otra clase con la funcionalidad extra que necesitas. Y puedes hacerlo sin modificar la original.

Suena genial.

Y aún así, a veces, me gustaría enviar largas temporadas al averno a quien la usa mal (que son muchas veces).

Tan convencido estoy de que la herencia es muy problemática que voy a prohibir, a partir de este mes, usar la herencia en los proyectos en los que estoy involucrado.

¿Qué tiene de malo la herencia de clases?

Es como un matrimonio sin posibilidad de divorcio

Cuando un matrimonio comienza suele ser todo maravilloso, todo fluye y encaja. Pero pasa el tiempo y la otra persona va cambiando. Esa persona ya no es la que era y estás atado a ella.

Piensa en esto. Una persona crea una clase que hace parte de lo que necesitas. Y piensas ¡esta clase está genial! Pero necesito que haga alguna cosa extra. ¡Ya sé! Voy a crear una nueva clase que herede de ésta.

Ahora tu clase está atada a la clase base sin remedio. Con suerte, según vaya evolucionando la clase base no se romperá nada en la tuya. Con suerte.

Y si la clase madre evoluciona de una manera incompatible no te quedará más remedio que anclarte en una de sus versiones desfasadas. Y eso es un problema.

Antes he dicho que puede ser un problema si te cambian la clase base. Pero ¿y si la clase base es tuya? Si sabes que tu clase está siendo usada por otra gente no tendrás libertad para añadir o quitar métodos o propiedades por el miedo a «romper» algo.

Su árbol genealógico no tiene fin

La cosa puede empeorar. Ya tienes tu clase que hereda de otra ¿Pero por qué parar ahí? Puedes crear otra clase que herede de la hija. Y otra que herede de la anterior.

Al final acabas con un montón de clases «acopladas» entre sí y tu aplicación se convierte en un monstruo devorador de tiempo, paciencia y recursos imposible de mantener.

Acabas con montones métodos innecesarios

Y, claro, con tanta clase heredada acabas con un montón de métodos y propiedades que, lo más seguro, sean totalmente innecesarias.

Puede ser un infierno entender el código

Mirar el código de una clase que hereda de otra u otras puede ser algo infernal. Tienes que andar revisando la propia clase o alguna de sus antecesoras. Y ya si tenemos «override» de métodos ya ni te cuento.

¿Y qué uso si no puedo usar la herencia?

Pues hay otras opciones como usar la composición. Si tenemos una clase que hace parte del trabajo que queremos ¿por qué no pasarla como parámetro al constructor de nuestra clase para usarla en lugar de heredar de ella?

O mejor aún ¿por qué no usar un interface? Pero esto ya lo dejo para otro día.

Deja un comentario