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

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 533 — #571
✐
13. Recuerde una regla fundamental de la ingeniería del software 1 : Todos los problemas
del diseño de software se puede simplificar introduciendo una nivel más de
indirección conceptual. Esta única idea es la pase de la abstracción, la principal
cualidad de la programación orientada a objetos.
14. Haga clases tan atómicas como sea posible: Es decir, dé a cada clase un propósito
único y claro. Si el diseño de su clase o de su sistema crece hasta ser
demasiado complicado, divida las clases complejas en otras más simples. El
indicador más obvio es tamaño total: si una clase es grande, FIXME: chances
are it’s doing demasiado y debería dividirse.
15. Vigile las definiciones de métodos largos. Una función demasiado larga y complicada
es dificil y cara de mantener, y es problema que esté intentado hacer
demasiado trabajo por ella misma. Si ve una función así, indica que, al menos,
debería dividirse en múltiples funciones. También puede sugerir la creación de
una nueva clase.
16. Vigile las listas de argumentos largas. Las llamadas a función se vuelven difíciles
de escribir, leer y mantener. En su lugar, intente mover el método a una
clase donde sea más apropiado, y/o pasele objetos como argumentos.
17. No se repita. Si un trozo de código se repite en muchos métodos de las clases
derivadas, ponga el código en un método de la clase base e invóquelo desde
las clases derivadas. No sólo ahorrará código, también facilita la propagación
de los cambios. Puede usar una función inline si necesita eficiencia. A veces
el descubrimiento de este código común añadirá funcionalidad valiosa a su
interface.
18. Vigile las sentencias switch o cadenas de if-else. Son indicadores típicos
de código dependiente del tipo, lo que significa que está decidiendo qué código
ejecutar basándose en alguna información de tipo (el tipo exacto puede no ser
obvio en principio). Normalemente puede reemplazar este tipo de código por
herencia y polimorfismo; una llamada a una función polimórfica efectuará la
comprobación de tipo por usted, y hará que el código sea más fiable y sencillo
de extender.
19. Desde el punto de vista del diseño, busque y distinga cosas que cambian y
cosas que no cambian. Es decir, busque elementos en un sistema que podrían
cambiar sin forzar un rediseño, después encapsule esos elementos en clases.
Puede aprender mucho más sobre este concepto en el capítulo Dessign Patterns
del Volumen 2 de este libro, disponible en www.BruceEckel.com 2
20. Tenga cuidado con las FIXME discrepancia. Dos objetos semánticamente diferentes
puede tener acciones idénticas, o responsabilidades, y hay una tendencia
natural a intentar hacer que una sea subclase de la otra sólo como beneficio
de la herencia. Ese se llama discrepancia, pero no hay una justificación real para
forzar una relación superclase/subclase donde no existe. Un solución mejor
es crear una clase base general que produce una herencia para las dos como
clases derivadas - eso require un poco más de espacio, pero sigue beneficiandose
de la herencia y probablemente hará un importante descubrimiento sobre
el diseño.
1 Que me explicó Andrew Koening.
2 (N. de T.) Está prevista la traducción del Volumen 2 por parte del mismo equipo que ha traducido
este volumen. Visite FIXME
533
✐
✐
✐
✐