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

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 24 — #62
✐
Capítulo 1. Introducción a los Objetos
2. Montaje de objetos. Si está construyendo un objeto descubrirá la necesidad de
nuevos miembros que no aparecen durante la fase de descubrimiento. Las necesidades
internas del objeto pueden requerir otras clases que le den soporte.
3. Construcción del sistema. Una vez más, pueden aparecer más requisitos para
un objeto a lo largo de esta etapa. Conforme aprende, evoluciona sus objetos.
La necesidad de comunicación e interconexión con otros objetos en el sistema
puede cambiar las necesidades de sus clases o requerir clases nuevas. Por ejemplo,
puede descubrir la necesidad de clases utilería o ayudantes (helper), como
una lista enlazada, que contienen o no una pequeña información de estado y
que simplemente ayudan a la función de otras clases.
4. Extensión del sistema. Cuando añada nuevas características a un sistema puede
descubrir que su diseño previo no soportaba extensiones sencillas del sistema.
Con esta nueva información, puede reestructurar partes del sistema, posiblemente
añadiendo nuevas clases o jerarquía de clases.
5. Reutilización de objetos. Esta es la verdadera prueba de estrés para una clase. Si
alguien intenta reutilizarla en una situación completamente nueva, probablemente
descubrirá algunos defectos. Si cambia una clase para adaptarla a nuevos
programas, los principios generales de la clase se verán más claros, hasta
que consiga un tipo verdaderamente reutilizable. Sin embargo, no espere que
muchos objetos del diseño de un sistema sean reutilizables -es perfectamente
aceptable que la mayor parte de los objetos sean específicos para el sistema. Los
tipos reutilizables tienden a ser menos comunes, y deben resolver problemas
más generales para ser reutilizables.
Directrices para desarrollo de objetos
Estas etapas sugieren algunas directrices cuando se piensa sobre el desarrollo de
clases:
1. Permita que un problema específico dé lugar a una clase, después deje que la
clase crezca y madure durante la solución de otros problemas.
2. Recuerde, descubrir las clases que necesita (y sus interfaces) supone la mayor
parte del diseño del sistema. Si ya tenía esas clases, será un proyecto fácil.
3. No se esfuerce por saber todo desde el principio; aprenda conforme avanza.
Ocurrirá así de todos modos.
4. Comience a programar; consiga tener algo funcionando para poder aprobar o
desaprobar su diseño. No tenga miedo a que acabe haciendo código procedural
espagueti -las clases dividen el problema y ayudan a controlar la anarquía y la
entropía. Las clases malas no estropean las buenas.
5. Manténgalo simple. Pequeños objetos claros con utilidades obvias son mejores
que grandes interfaces complicadas. Cuando aparezcan los puntos de decisión,
aplique el principio de la Navaja de Occam: Considere las alternativas y elija
la más simple, porque las clases simples casi siempre son mejores. Empiece
con clases pequeñas y sencillas, y podrá ampliar la interfaz cuando la entienda
mejor, pero cuando esto ocurra, será difícil eliminar elementos de la clase.
24
✐
✐
✐
✐