Principio Abierto-Cerrado en C# para Extender Código sin Modificarlo

Comprender cómo diseñar software que pueda crecer sin romper lo que ya funciona es una de las habilidades más valiosas en el desarrollo profesional. El principio abierto cerrado (open closed principle) ofrece exactamente esa guía: construir componentes que se puedan extender sin necesidad de alterar el código que ya está comprobado y en producción.

¿Qué establece el principio abierto cerrado?

Este principio, atribuido a Bertrand Meyer y popularizado por Robert Martin en su libro de Clean Code, forma parte de los principios SOLID [00:24]. Su enunciado es directo: un componente dentro de un sistema debe ser abierto para extensiones y cerrado para cambios.

En la práctica esto significa que el código que ya está funcionando, que ya fue probado y validado, no debería modificarse cuando se necesiten agregar nuevas funcionalidades. En lugar de eso, la arquitectura debe estar preparada para que se le añadan módulos o comportamientos nuevos sin tocar lo existente [01:24].

¿Por qué es importante conocerlo en inglés?

En entrevistas técnicas es muy probable que te pregunten por el open closed principle usando su nombre en inglés [00:35]. Además, buscar información y ejemplos avanzados en inglés permite profundizar mucho más en su aplicación real. Conocer la terminología en ambos idiomas te da una ventaja clara.

¿Cómo se relaciona con los demás principios SOLID?

Robert Martin no inventó cada principio de forma aislada; lo que hizo fue reunir buenas prácticas y principios ya existentes y organizarlos bajo el acrónimo SOLID [01:05]. El principio abierto cerrado complementa al resto porque obliga a pensar en diseños donde cada pieza tiene una responsabilidad clara y puede evolucionar de forma independiente.

¿Cómo se extiende el código sin modificarlo?

La clave está en apoyarse de tipos abstractos. En el caso de C#, se utilizan abstracciones como interfaces y clases abstractas para definir contratos que los nuevos módulos pueden implementar [01:55]. De esta forma:

• Se crean contratos claros que describen el comportamiento esperado.
• Los nuevos requerimientos se resuelven con nuevas implementaciones, no editando las existentes.
• El sistema gana flexibilidad sin sacrificar estabilidad.

Cuando llega un requerimiento nuevo —un módulo adicional o una funcionalidad diferente— no se toca el código que ya funciona. Se extiende creando una nueva clase que cumple con la abstracción definida previamente.

¿Qué problema resuelve en el día a día?

Sin este principio, cada cambio obliga a abrir archivos que ya estaban estables, lo que incrementa el riesgo de introducir errores. Al aplicar el open closed principle, el equipo puede agregar valor al producto con mayor confianza, ya que las partes probadas permanecen intactas.

Si ya estás trabajando con C# u otro lenguaje orientado a objetos, prueba identificar en tu proyecto actual un componente que podrías reestructurar para que sea abierto a extensiones y cerrado a modificaciones. Comparte tu experiencia y cómo te fue aplicándolo.