La herencia como anti-esquema

Aún existe demasiada gente que considera que la herencia es algo bueno. Justo la misma gente que, acostumbrados a ella en lenguajes como Java, está presionando para que Javascript la adopte. Pero ¿tan positiva es?

Tal y como afirman Kas Thomas, Joshua Bloch o Bernard Sumption, la herencia viola el principio de encapsulación y tiende a convertirse en un anti-esquema (antipattern) ya que requiere que los hijos conozcan el funcionamiento de los padres. Además la polución en las clases heredadas resulta evidente: la clase JMenu de java contiene 433 métodos, la inmensa mayoría heredados. Un cambio en un método ancestro puede romper los hijos de forma inesperada. Y para muestra, un botón de la propia documentación de Java para la clase Properties:

Puesto que Properties hereda de Hashtable, los métodos put y putAll pueden ser aplicados también a un objeto Properties. Su uso, sin embargo, está fuertemente desaconsejado ya que permiten que el llamante inserte entradas cuyas claves o valores no sean Strings. El método setProperty debe usarse en su lugar. Si los métodos store o save son llamados sobre un objeto Properties "comprometido" que contiene una clave o valor que no sea String, la llamada fracasará.

Si Brendan Eich optó por los prototipos fue por algo. Pero sus motivaciones son totalmente desconocidas para toda esa horda de programadores (provenientes de Java en su mayor parte) que insisten en que Javascript soporte este imperfecto o polémico mecanismo. Gosling, Eich, Bloch, Holub, saben de lo que hablan.