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 queProperties
hereda deHashtable
, los métodosput
yputAll
pueden ser aplicados también a un objetoProperties
. Su uso, sin embargo, está fuertemente desaconsejado ya que permiten que el llamante inserte entradas cuyas claves o valores no seanString
s. El métodosetProperty
debe usarse en su lugar. Si los métodosstore
osave
son llamados sobre un objetoProperties
"comprometido" que contiene una clave o valor que no seaString
, 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.
0 comentarios:
Publicar un comentario