14.9. Desarrollo incremental

Una de las ventajas de la herencia y la composición es que favorecen el desarrollo incremental, ya que permiten introducir código nuevo sin provocar errores en el código existente. Si aparecen errores, quedan aislados dentro del código nuevo. Al heredar de (o componer con) una clase existente que funciona y añadir atributos y funciones miembro (y redefinir funciones miembro existentes durante la herencia), el código existente (que puede que alguien más siga utilizando) queda intacto y libre de errores. Si se produce un error, sabe que está en el código nuevo, que es mucho más corto y fácil de leer que si hubiera modificado el cuerpo del código existente.

Es bastante sorprendente lo limpiamente que quedan separadas las clases. Ni siquiera se necesita el código fuente de las funciones miembro para reutilizar el código; basta con el fichero de cabecera que describe la clase y el fichero objeto o el fichero de librería con las funciones miembro compiladas. (Esto es válido tanto para la herencia como para la composición.)

Es importante darse cuenta de que el desarrollo de un programa es un proceso incremental, igual que el aprendizaje humano. Puede hacer todo el análisis que quiera, pero aun así no sabrá todas las respuestas cuando empiece un proyecto. Tendrá mucho más éxito (y una realimentación más inmediata) si empieza a «hacer crecer» su proyecto como una criatura orgánica y evolutiva, en lugar de construirlo todo de una vez como un rascacielos de cristal[76].

Aunque la herencia es una técnica útil para experimentar, en algún momento, cuando las cosas se hayan estabilizado, necesitará volver a examinar su jerarquía de clases con la idea de reducirla a una estructura sensata[77]. Recuerde que, en el fondo, la herencia pretende expresar una relación que dice: «Esta nueva clase es un tipo de aquella vieja clase». Su programa no debería ocuparse de mover bits de un lado a otro, sino de crear y manipular objetos de varios tipos para expresar un modelo en los términos que le proporciona el espacio del problema.



[76] Para saber más sobre esta idea, vea Extreme Programming Explained, de Kent Beck (Addison-Wesley, 2000).

[77] Vea Refactoring: Improving the Design of Existing Code, de Martin Fowler (Addison-Wesley, 1999).