Pensar en C++ (Volumen 1) - Grupo ARCO

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 534 — #572
✐
Apéndice B. Directrices de Programación
21. Tenga cuidado con la FIXME: limitación de la herencia. Los diseños más límpios
añaden nuevas capacidades a las heredadas. Un diseño sospechoso elimina
capacidades durante la herencia sin añadir otras nuevas. Pero las reglas están
hechas para romperse, y si está trabajando con una librería antigua, puede ser
más eficiente restringir una clase existente en sus subclases que restructurar
la jerarquía de modo que la nueva clase encaje donde debería, sobre la clase
antigua.
22. No extienda funcionalidad fundamental por medio de subclases. Si un elemento
de la interfaz es esecial para una clase debería estár en la clase base, no
añadido en una clase derivada. Si está añadiendo métodos por herencia, quizá
debería repensar el diseño.
23. Menos es más. Empiece con una interfaz mínima a una clase, tan pequeña y
simple como necesite para resolver el problema que está tratando, pero no intente
anticipar todas las formas en las que se podría usar la clase. Cuando use
la clase, descubrirá formas de usarla y deberá expandir la interface. Sin embargo,
una vez que que la clase esté siendo usada, no podrá reducir la interfaz sin
causar problemas al código cliente. Si necesita añadir más funciones, está bien;
eso no molesta, únicamente obliga a recompilar. Pero incluso si los nuevos métodos
reemplazan las funcionalidad de los antiguos, deje tranquila la interfaz
existente (puede combinar la funcionalidad de la implementación subyacente
si lo desea. Si necesita expandir la interfaz de un método existente añadiendo
más argumentos, deje los argumentos existentes en el orden actual, y ponga valores
por defecto a todos los argumentos nuevos; de este modo no perturbará
ninguna de las llamadas antiguas a esa función.
24. Lea sus clases en voz alta para estar seguro que que suenan lógicas, refiriendose
a las relación entre una clase base y una clase derivada com «es-un» y a los
objetos miembro como «tiene-un».
25. Cuando tenga que decidir entre herencia y composición, pregunte si necesita
hacer upcast al tipo base. Si la respuesta es no, elija composición (objetos
miembro) en lugar de herencia. Esto puede eliminar la necesidad de herencia
múltiple. Si hereda, los usuarios pensarán FIXME:they are supposed to upcast.
26. A veces, se necesita heredar para acceder a miembros protegidos de una clase
base. Esto puede conducir a una necesidad de herencia múltiple. Si no necesita
hacer upcast, primero derive una nueva clase para efectuar el acceso protegido.
Entonces haga que la nueva clase sea un objeto miembro dentro de cualquier
clase que necesite usarla, el lugar de heredar.
27. Típicamente, una clase base se usará principalmente para crear una interface
a las clases que hereden de ella. De ese modo, cuando cree una clase base,
haga que por defecto los métodos sean virtuales puros. El destructor puede
ser también virtual puro (para forzar que los derivadas tengan que anularlo
explicitamente), pero recuerde poner al destructor un cuerpo, porque todos
destructores de la jerarquía se ejecutan siempre.
28. Cuando pone un método virtual puro en una clase, haga que todos los métodos
de la clase sean también viruales, y ponga un constructor virtual. Esta
propuesta evita sorpresas en el comportamiento de la interfaz. Empiece a quitar
la palabra virtual sólo cuando esté intentando optimizar y su perfilador
haya apuntado en esta dirección.
534
✐
✐
✐
✐