Sofía siempre había sido una mente inquieta. Estudiaba ingeniería en sistemas, pero hasta cierto punto la programación le parecía un rompecabezas interminable. Cada vez que escribía código estructurado, sentía que estaba parchando una tela llena de agujeros. “¿Por qué todo parece tan frágil? ¿Por qué cada cambio rompe lo demás?”, se preguntaba al ver su proyecto colapsar una y otra vez.

Un día, su profesor le habló de los lenguajes de programación orientados a objetos (POO). Hablaba de clases, herencia, encapsulamiento y polimorfismo como si fueran piezas mágicas que podían transformar el caos en orden. Sofía, intrigada, decidió sumergirse en ese nuevo paradigma.

La transición no fue fácil. Descubrió que las características de la POO —la abstracción para simplificar lo complejo, el encapsulamiento para proteger datos, la herencia para reutilizar código y el polimorfismo para dar flexibilidad— eran poderosas, pero también exigían disciplina mental. No bastaba con programar: debía pensar como un arquitecto de sistemas, no como un reparador de errores.

Al avanzar, Sofía notó las ventajas: sus programas eran más fáciles de mantener, podía agregar nuevas funciones sin romper las anteriores y empezó a trabajar en equipo con mayor fluidez, porque todos hablaban el mismo “lenguaje visual” de objetos. Sin embargo, también se topó con las desventajas: el diseño inicial consumía más tiempo, y a veces la abstracción la alejaba de la simplicidad que tanto valoraba en el código estructurado.

El conflicto llegó en un hackatón. Sofía debía liderar a su equipo para construir un prototipo en 24 horas. El dilema era claro: ¿arriesgarse con POO y perder tiempo en diseño, o regresar al viejo estilo estructurado que ya conocía? Decidió confiar en lo aprendido. Creó clases base, definió relaciones y delegó tareas con claridad.

El resultado fue inesperado: no solo terminaron a tiempo, sino que su proyecto fue premiado por la claridad y escalabilidad del código. Sofía comprendió que la POO no era solo una técnica, sino una forma de pensar: organizar la complejidad con visión a futuro.

Aquella experiencia le dejó una enseñanza poderosa: en la vida, como en la programación, no basta con resolver el problema inmediato. Hay que diseñar pensando en lo que vendrá, construir con bases sólidas y aceptar que cada decisión implica ventajas y limitaciones.