El primer paso es algún tipo de estudio. 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 alucina con 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 enseñanza a todos los niveles de la compañía a la vez, incluir una visión general de los cursos para gerentes estratégicos es tan bueno como cursos de diseño y programación para trabajadores de proyectos. Es especialmente bueno para compañías más pequeñas al hacer cambios fundamentales en la forma en la que se hacen cosas, o en la división de niveles en compañías más grandes. Como el coste es mayor, sin embargo, se puede cambiar algo al empezar con entrenamiento de nivel de proyecto, hacer un proyecto piloto (posiblemente con un mentor externo), y dejar que el equipo de trabajo se convierta en los profesores del resto de la compañía.

Pruebe primero con un proyecto de bajo riesgo que permita errores. Una vez que adquiera alguna experiencia, puede acometer cualquier otro proyecto con miembros del primer equipo 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, pero no debería ser una tarea crítica para la compañía. Debería ser simple, auto-contenido, e instructivo; eso significa que suele 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++.

Buscar 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 ellos no lo han resuelto probablemente puede aplicar lo que ha aprendido sobre abstracción para modificar un diseño existente y adecuarlo a sus necesidades. Este es el concepto general de los patrones de diseño, tratado en el Volumen 2.

La primera 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 las librerías de fábrica. No obstante, algunos programadores nuevos no lo entienden, no son conscientes de la existencia de librerías de clases, o, a través de la fascinación con el lenguaje, desean escribir clases que 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 es importante reutilizar el código. Pero esos cambios no le van a mostrar los espectaculares incrementos en productividad que espera para sus primeros proyectos a menos que ese proyecto sea nuevo. C++ y la POO destacan más cuando un proyecto pasa del concepto a la realidad.