El primer paso es algún tipo de formación. Recuerde la inversión que la compañía tiene en código C, e intente no tenerlo todo desorganizado durante seis o nueve meses mientras todo el mundo se devana los sesos intentando entender cómo funciona la herencia múltiple. Elija un pequeño grupo para formarlo, preferiblemente uno compuesto de gente que sea curiosa, trabaje bien junta, y pueda funcionar como su propia red de soporte mientras están aprendiendo C++.

Un enfoque alternativo que se sugiere a veces es la formación de todos los niveles de la compañía a la vez, incluyendo cursos de visión general para directivos estratégicos y cursos de diseño y programación para quienes construyen los proyectos. Es especialmente adecuado para compañías pequeñas que están haciendo cambios fundamentales en su forma de trabajar, o a nivel de división en compañías más grandes. Sin embargo, como el coste es mayor, algunos pueden preferir empezar con formación a nivel de proyecto, hacer un proyecto piloto (posiblemente con un mentor externo), y dejar que el equipo del proyecto se convierta en el profesor del resto de la compañía.

Pruebe primero con un proyecto de bajo riesgo y cuente con que habrá errores. Una vez que adquiera alguna experiencia, puede repartir a los miembros de este primer equipo entre otros proyectos o usar los miembros del equipo como una plantilla de soporte técnico de POO. Este primer proyecto puede que no funcione bien la primera vez, así que no debería ser una tarea crítica para la compañía. Debería ser simple, auto-contenido, e instructivo; eso significa que debería implicar la creación de clases que serán significativas para otros programadores en la compañía cuando les llegue el turno de aprender C++.

Busque ejemplos de un buen diseño orientado a objetos antes de partir de cero. Hay una gran probabilidad de que alguien ya haya resuelto su problema, y si no lo ha resuelto exactamente, probablemente puede aplicar lo que ha aprendido sobre abstracción para modificar un diseño existente y adecuarlo a sus necesidades. Éste es el concepto general de los patrones de diseño, tratado en el Volumen 2.

La principal motivación económica para cambiar a POO es el fácil uso de código existente en forma de librerías de clases (en particular, las librerías Estándar de C++, explicadas en profundidad en el Volumen 2 de este libro). El ciclo de desarrollo de aplicación más corto ocurrirá cuando sólo tenga que escribir la función main(), creando y usando objetos de librerías ya disponibles. No obstante, algunos programadores nuevos no lo entienden, no son conscientes de la existencia de librerías de clases, o, por fascinación con el lenguaje, desean escribir clases que quizá ya existen. Su éxito con POO y C++ se optimizará si hace un esfuerzo por buscar y reutilizar código de otras personas desde el principio del proceso de transición.

Aunque compilar su código C con un compilador de C++ normalmente produce (de vez en cuando tremendos) beneficios encontrando problemas en el viejo código, normalmente coger código funcional existente y reescribirlo en C++ no es la mejor manera de aprovechar su tiempo. (Si tiene que convertirlo en objetos, puede «envolver» el código C en clases C++). Hay beneficios incrementales, especialmente si está previsto reutilizar el código. Pero lo más probable es que no vea los espectaculares incrementos de productividad que espera en sus primeros proyectos, a menos que se trate de un proyecto nuevo. C++ y la POO destacan más cuando un proyecto pasa del concepto a la realidad.