Cambios en el diseño de la clase base después de la implementación
Actualización: noviembre 2007
Lo ideal sería que las jerarquías de clases nunca cambiaran después de su implementación, puesto que incluso los pequeños cambios pueden tener consecuencias no deseadas. En realidad, estos cambios no siempre pueden evitarse: los requisitos del producto pueden cambiar y las especificaciones de diseño a veces omiten elementos clave. Una categoría de problemas de herencia se denomina el problema de fragilidad de la clase base.
El problema de fragilidad de la clase base
El principal inconveniente de utilizar jerarquías de herencia es un problema denominado fragilidad de las clases base. Para cambiar clases base suele ser necesario cambiar, volver a compilar y redistribuir la clase base y todo el código de las clases derivadas. Este problema es aún mayor cuando son varios los autores de la clase base y de las clases derivadas, puesto que cada uno puede denegar el acceso a su código fuente. En el peor de los casos, un cliente podría utilizar sin darse cuenta la forma binaria compilada de una clase base actualizada con el original y la versión binaria incompatible de las clases derivadas.
Los cambios en la clase base que pueden interrumpir las clases derivadas incluyen el reemplazar o cambiar el tipo de datos de los miembros de la clase base.
Minimizar los problemas de fragilidad de la clase base
La mejor manera de evitar el problema de fragilidad de la clase base consiste en realizar los cambios sólo en las clases derivadas. No obstante, esto no siempre es posible porque es necesario considerar todas las posibilidades cuando se libera por primera vez la clase base; a pesar de todos los esfuerzos realizados en este sentido, a veces los cambios imprevisibles en la clase base son inevitables.
El uso de clases MustInherit y métodos MustOverride ayuda a reducir los problemas de fragilidad de la clase base, puesto que así los detalles de la implementación se trasladan a las clases derivadas y se reduce la necesidad de cambios en la clase base. Una vez más, esto no siempre es posible, ni siquiera con el mejor planeamiento.
Los miembros de datos sombreados en clases derivadas también sirven de ayuda, puesto que reducen los conflictos de nomenclatura con los miembros de la clase base.
La forma más segura de extender la funcionalidad de una clase base consiste en agregar nuevos miembros. Los nuevos miembros sólo podrán interrumpir una clase base si la clase derivada utiliza la palabra clave Overloads para heredar métodos de la clase base e introducir nuevos métodos con el mismo nombre. Este problema puede evitarse mediante la especificación explícita en la clase derivada de los métodos de la clase base que desea heredar y redefiniendo esos métodos y delegando en ellos.
De alguna manera, todas las clases base tienen cierto grado de fragilidad. En el análisis final, el problema de fragilidad de la clase base no se puede eliminar, pero sí minimizar mediante un diseño cuidadoso de las jerarquías de clases que reduzca la necesidad de realizar cambios en la clase base y mediante la realización de pruebas exhaustivas cuando tales cambios sean inevitables.