Definición Formal
El principio OCP (Open/Closed Principle) establece que el código de una clase o un módulo debe estar abierto para la extensión, pero cerrado para la modificación. Esto significa que no se deben realizar cambios en el código existente cuando se requiere alterar alguna funcionalidad. En lugar de modificar el código existente, se debe crear una nueva implementación que extienda la funcionalidad. La única excepción a esto son los arreglos de bugs, donde está permitido modificar el código existente.
Si se desea introducir una nueva funcionalidad, como la ordenación en un método existente, en lugar de modificar el código, se crearía una nueva implementación que implementara la misma interfaz.
El principio OCP fomenta la creación de código más robusto y flexible, minimizando la introducción de errores en el sistema. Siguiendo también el principio de segregación de interfaces, se pueden crear interfaces más pequeñas, lo que facilitaría la implementación de nuevos servicios sin tener que reescribir todo el código. La combinación de OCP e IS (Interface Segregation) permite que los desarrolladores mantengan un código limpio y escalable.
Las ventajas de no modificar el código existente, permite que los casos de prueba que ya están escritos para la implementación sigan siendo relevantes y no necesiten revisión. Esto ahorra tiempo y esfuerzo en producción, y permite a los clientes seguir usando la funcionalidad antigua si así lo desean.
Bertrand Meyer fue quien formuló originalmente el Principio Abierto/Cerrado (OCP) en su libro "Object-Oriented Software Construction" (1988).
Definición de Meyer:
Una entidad de software (clase, módulo, función, etc.) debe estar abierta para extensión, pero cerrada para modificación.
Luego, este principio fue adoptado por Robert C. Martin (tío Bob) y pasó a formar parte de los Principios SOLID, que son muy relevantes en la programación orientada a objetos.
En resumen, Meyer lo introdujo y Martin lo popularizó dentro del marco de SOLID.
Ejemplo: Cálculo de áreas
Supongamos que queremos calcular el área de diferentes figuras geométricas sin modificar el código existente cuando agregamos una nueva figura.
Código sin OCP (violando el principio)
En este caso, cada vez que agregamos una nueva figura, debemos modificar la clase AreaCalculator, lo que viola el OCP porque el código no está cerrado a modificaciones:
public class Circulo
{
public double Radio { get; }
public Circulo(double radio)
{
Radio = radio;
}
}
public class Rectangulo
{
public double Ancho { get; }
public double Alto { get; }
public Rectangulo(double ancho, double alto)
{
Ancho = ancho;
Alto = alto;
}
}
public class CalculadoraDeArea
{
public double CalcularArea(object figura)
{
if (figura is Circulo c)
{
return 3.14 * c.Radio * c.Radio;
}
else if (figura is Rectangulo r)
{
return r.Ancho * r.Alto;
}
else
{
throw new ArgumentException("Figura no soportada");
}
}
}
Si queremos agregar una nueva figura (Triángulo), tendríamos que modificar la CalculadoraDeArea, violando el OCP.
Ejemplo Correcto (Cumple OCP)
Acá usamos herencia y polimorfismo para que la CalculadoraDeArea no necesite modificaciones al agregar nuevas figuras.// Definimos una interfaz para garantizar que todas las figuras implementen el método CalcularArea()
public interface IFigura
{
double CalcularArea();
}
// Creamos la clase Circulo que implementa la interfaz IFigura
public class Circulo : IFigura
{
public double Radio { get; }
public Circulo(double radio)
{
Radio = radio;
}
public double CalcularArea()
{
return Math.PI * Radio * Radio;
}
}
// Creamos la clase Rectangulo que implementa la interfaz IFigura
public class Rectangulo : IFigura
{
public double Ancho { get; }
public double Alto { get; }
public Rectangulo(double ancho, double alto)
{
Ancho = ancho;
Alto = alto;
}
public double CalcularArea()
{
return Ancho * Alto;
}
}
// Nueva funcionalidad: Agregamos la clase Triángulo sin modificar el código de las otras figuras
public class Triangulo : IFigura
{
public double Base { get; }
public double Altura { get; }
public Triangulo(double baseT, double altura)
{
Base = baseT;
Altura = altura;
}
public double CalcularArea()
{
return (Base * Altura) / 2;
}
}
// Uso del código en el método Main
class Program
{
static void Main()
{
// Creamos un círculo con radio 5
Circulo circulo = new Circulo(5);
Console.WriteLine("El área del círculo es: " + circulo.CalcularArea());
// Creamos un rectángulo de 4x6
Rectangulo rectangulo = new Rectangulo(4, 6);
Console.WriteLine("El área del rectángulo es: " + rectangulo.CalcularArea());
// Creamos un triángulo de base 3 y altura 4
Triangulo triangulo = new Triangulo(3, 4);
Console.WriteLine("El área del triángulo es: " + triangulo.CalcularArea());
}
}
Si queremos agregar un Triángulo, solo creamos una nueva clase Triangulo sin modificar CalculadoraDeArea. El código es más mantenible y flexible, porque es modular. Este ejemplo cumple con el principio de OC, ya que CalculadoraDeArea está cerrada para modificaciones y abierta para extensiones.
Desventajas del OCP
Aaunque el Principio Abierto/Cerrado (OCP) ofrece muchas ventajas, también tiene algunas desventajas que es importante considerar, no todo es perfecto en la vida.
Aumento en la complejidad del código
- Para cumplir con OCP, a menudo se necesita más abstracción (interfaces, clases base, polimorfismo), lo que puede hacer que el código sea más difícil de entender y mantener.
- En proyectos pequeños, esta estructura puede ser innecesaria y sobrecomplicar la solución.
Mayor cantidad de clases e interfaces
- Aplicar OCP correctamente suele implicar la creación de múltiples interfaces y clases nuevas cada vez que se requiere un cambio.
- Esto puede llevar a una explosión de clases y archivos, dificultando la navegación del código.
Posible sobrecarga de memoria o rendimiento
- En algunos casos, el uso excesivo de abstracciones puede impactar el rendimiento debido a la sobrecarga de instancias de objetos y llamadas a métodos virtuales o inyección de dependencias.
Mayor esfuerzo inicial en el diseño
- Implementar OCP correctamente requiere pensar en la extensibilidad desde el principio, lo que puede aumentar el tiempo de desarrollo inicial.
- Si no se tiene un diseño adecuado, se pueden crear estructuras innecesariamente complejas que nunca se van a reutilizar.
Dificultad en cambios de gran porte
- Si bien OCP permite agregar nuevas funcionalidades sin mdificar el código existente, si la estructura base no está bien diseñada, extenderla puede volverse complicado y requerir una refactorización importante.
Cuándo aplicar OCP y cuándo no
- Usalo cuando esperas que tu sistema crezca y necesite nuevas funcionalidades sin afectar el código existente.
- Evítalo en proyectos pequeños donde la flexibilidad futura no es una preocupación inmediata.
En conclusión, OCP es un principio potente que mejora la mantenibilidad y escalabilidad, pero debe usarse con criterio para evitar sobrecomplicaciones innecesarias cuando no lo amerita. Tampoco hay que obsesionarse.
