HerenciaDiseñada

Escrito por Martin Fowler
Traducido por Rafael Vacas

Uno de los más largos debates en los círculos orientados a objetos es el debate entre HerenciaAbierta y HerenciaDiseñada. Josh Block ha sido probablemente quien mejor ha resumido el principio de la herencia diseñada: “Diseña y documenta para herencia o si no prohíbela”. Con este planteamiento te preocupas de decidir qué métodos pueden ser heredados y proteges los otros para evitar que sean sobrescritos.

El argumento más común para la herencia diseñada es que dado que la herencia supone una relación muy estrecha (y rompe la encapsulación) es fácil que las subclases efectivamente rompan las superclases por ejemplo, omitiendo comportamientos necesarios cuando sus métodos son invocados.

Muchos programadores, particularmente aquellos con una ActitudPermisiva, no están muy convencidos por este estilo de argumento. Otro argumento que encuentro más apetecible es el de Elliote Rusty Harold al discutir los principios de diseño de XOM. La cuestión aquí es que “las API son escritas por expertos para no expertos”. El creador de librerías debería estar debidamente versado en la tecnología con la que trabaja la librería. Deberían trabajar para simplificar esta tecnología a los usuarios de la librería. La encapsulación consiste en esconder secretos, por tanto una buena librería debería esconder toda clase de complicaciones y puntos peligrosos a los usuarios de la librería, ya usen la librería mediante invocaciones o herencia. Por tanto, con XOM puedo sobrescribir de forma segura las clases de la librería para hacer lo que quiera ya que la librería garantiza que aún así producirá XML bien formado, sin que tenga que preocupar a mi fea cabecita con todas las cosas que de otra forma podrían ir mal.

Este argumento me convence mucho más que el usual que deja entrever que los creadores de librerías son listos y los usuarios tontos. No se trata de habilidad, sino de conocimiento conciso. Quiero ser tan ignorante como pueda sobre los sórdidos detalles de XML. Al liberarme de la necesidad de entender este tipo de detalles, puedo usar toda la potencia de mi cerebro a la tarea concreta que quiero lograr.

A pesar de este persuasivo argumento, mi instinto y el hecho de que tengo una actitud permisiva, tiende a preferir la herencia abierta. Quizás el quid del problema es el mecanismo que usamos para señalar áreas seguras de herencia. Generalmente toda nuestra habilidad consiste en bloquear clases y métodos. Una alternativa para aplacar ambos campos seria tener la habilidad de saltarse un bloqueo. De esa forma tienes que apañártelas a tu manera para sobrescribir algo que no fue diseñado. Si no abres explícitamente un bloqueo entonces el compilador solo permite herencia normal, pero si usas el mecanismo rompe-bloqueos entonces el compilador lo dejará en tus manos – y tu eres responsable de las consecuencias. Por tanto, preferiría sustituir el “prohíbe” de Josh Block por un “desaconseja”.

Tomando una visión en conjunto mi opinión es que todavía hay mucho campo para la mejora en cuanto a lo que pensamos sobre interfaces, ya sea invocando o heredando. Ideas como Contratos Dirigidos por el Cliente son necesarios para hacernos replantear lo que significa tener una definición de interfaz. No sé cual debería ser la respuesta pero creo que una buena respuesta nos sorprendería a todos.
Artículo Original