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

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 532 — #570
✐
Apéndice B. Directrices de Programación
6. Separe al creador de la clase del usuario de la clase (el programador cliente). El
usuario de la clase es el «consumidor» y no necesita o no quiere conocer que
hay dentro de la clase. El creador de la clase debe ser un experto en diseño
de clases y escribir la clase para que pueda ser usada por el programador más
inexperto posible, y aún así funcionar de forma robusta en la aplicación. El uso
de la librería será sencillo sólo is es transparente.
7. Cuando cree una clase, utilice nombres tan claros como sea posible. Eo objetivo
debería ser que la interface del programador cliente sea conceptualmente simple.
Intente utilizar nombres tan claros que los comentarios sean innecesarios.
Luego, use sobrecarga de funciones y argumentos por defecto para crear un
interface intuitiva y fácil de usar.
8. El control de acceso permite (al creador de la clase) cambiar tanto como sea
posible en el futuro sin afectar al código del cliente en el que se usa la clase.
FIXME:Is this light, mantenga todo tan privado como sea posible, y haga pública
solamente la interfaz de la clase, usando siempre métodos en lugar de
atributos. Ponga atributos públicos sólo cuando se vea obligado. Si una parte
de su clase debe quedar expuesta a clases derivadas como protegida, proporcione
una interface con funciones en lugar de exponer los datos reales. De este
modo, los cambios en la implementación tendrán un impacto mínimo en las
clases derivadas.
9. FIXME No caiga en FIXME:analysis paralysis. Hay algunas cosas que no aprenderá
hasta que empiece a codificar y consiga algún tipo de sistema. C++ tiene
mecanimos de seguridad de fábrica, dejelos trabajar por usted. Sus errores en
una clase o conjunto de clases no destruirá la integridad del sistema completo.
10. El análisis y diseño debe producir, como mínimo, las clases del sistema, sus
interfaces públicas, y las relaciones con otras clases, especialmente las clases
base. Si su metodología de diseño produce más que eso, preguntese a si mismo
si todas las piezas producidas por la metodología tiene valor respecto al tiempo
de vide del programa. Si no lo tienen, no mantenga nada que no contribuya a
su productividad, este es un FIXME:fact of life] que muchos métodos de diseño
no tienen en cuenta.
11. Escriba primero el código de las pruebas (antes de escribir la clase), y guardelo
junto a la clase. Automatice la ejecución de las pruebas con un makefile
o herramienta similar. De este modo, cualquier cambio se puede verificar
automáticamente ejecutando el código de prueba, lo que permite descubrir
los errores inmediatamante. Como sabe que cuenta con esa red de seguridad,
puede arriesgar haciendo cambios más grandes cuando descubra la necesidad.
Recuerde que las mejoras más importantes en los lenguajes provienen de las
pruebas que hace el compilador: chequeo de tipos, gestión de excepciones, etc.,
pero estas características no puede ir muy lejos. Debe hacer el resto del camino
creando un sistema robusto rellenando las pruebas que verifican las características
específicas de la clase o programa concreto.
12. Escriba primero el código de las pruebas (antes de escribir la clase) para verificar
que el diseño de la clase está completo. Si no puede escribir el código
de pruebas, significa que no sabe que aspecto tiene la clases. En resumen, el
echo de escribir las pruebas a menudo desvela características adicionales o restricciones
que necesita la clase - esas características o restricciones no siempre
aparecen durante el análisis y diseño.
532
✐
✐
✐
✐