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

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 35 — #73
✐
1.12. Estrategias de transición
ra entender la nueva tecnología. A lo largo del proceso ellos cometerán más errores
(esto es una ventaja, porque los errores reconocidos son el modo más rápido para
aprender) y ser menos productivos. Incluso entonces, con algunos tipos de problemas
de programación, las clases correctas y el entorno de programación adecuado,
es posible ser más productivo mientras se está aprendiendo C++ (incluso considerando
que está cometiendo más errores y escribiendo menos líneas de código por
día) que si estuviera usando C.
Cuestiones de rendimiento
Una pregunta común es, «¿La POO no hace automáticamente mis programas
mucho más grandes y lentos» La respuesta es: «depende». Los lenguajes de POO
más tradicionales se diseñaron con experimentación y prototipado rápido más que
pensando en la eficiencia. De esta manera, prácticamente garantiza un incremento
significativo en tamaño y una disminución en velocidad. C++ sin ambargo, está diseñado
teniendo presente la producción de programación. Cuando su objetivo es
un prototipado rápido, puede lanzar componentes juntos tan rápido como sea posible
ignorando las cuestiones de eficiencia. Si está usando una librerías de otros,
normalmente ya están optimizadas por sus vendedores; en cualquier caso no es un
problema mientras está en un modo de desarrollo rápido. Cuando tenga el sistema
que quiere, si es bastante pequeño y rápido, entonces ya está hecho. Si no, lo puede
afinar con una herramienta de perfilado, mire primero las mejoras que puede conseguir
aplicando las características que incorpora C++. Si esto no le ayuda, mire las
modificaciones que se pueden hacer en la implementación subyacente de modo que
no sea necesario cambiar ningún código que utilice una clase particular. Únicamente
si ninguna otra cosa soluciona el problema necesitará cambiar el diseño. El hecho de
que el rendimiento sea tan crítico en esta fase del diseño es un indicador de que debe
ser parte del criterio del diseño principal. FIXME:Usar un desarrollo rápido tiene la
ventaja de darse cuenta rápidamente.
Como se mencionó anteriormente, el número dado con más frecuencia para la
diferencia en tamaño y velocidad entre C y C++ es 10%, y a menudo menor. Incluso
podría conseguir una mejora significativa en tamaño y velocidad cuando usa C++
más que con C porque el diseño que hace para C++ puede ser bastante diferente
respecto al que hizo para C.
La evidencia entre las comparaciones de tamaño y velocidad entre C y C++ tienden
a ser anecdóticas y es probable que permanezcan así. A pesar de la cantidad de
personas que sugiere que una compañía intenta el mismo proyecto usando C y C++,
probablemente ninguna compañía quiere perder dinero en el camino a no ser que sea
muy grande y esté interesada en tales proyectos de investigación. Incluso entonces,
parece que el dinero se puede gastar mejor. Casi universalmente, los programadores
que se han cambiado de C (o cualquier otro lenguaje procedural) a C++ (o cualquier
otro lenguaje de POO) han tenido la experiencia personal de una gran mejora en
su productividad de programación, y es el argumento más convincente que pueda
encontrar.
Errores comunes de diseño
Cuando su equipo empieza con la POO y C++, típicamente los programadores
pasan por una serie de errores de diseño comunes. Esto ocurre a menudo porque
hay poca realimentación de expertos durante el diseño e implementación de los proyectos
iniciales, porque ningún experto ha sido desarrollador dentro de la compañía
y puede haber resistencia a contratar consultores. Es fácil pensar que se entiende la
POO demasiado pronto en el ciclo y se va por el mal camino. Algo que es obvio para
35
✐
✐
✐
✐