Principio de Abierto Cerrado

El Principio de Abierto/Cerrado o Open Close Principle (OCP), es una directriz clave en el desarrollo de software que busca la eficiencia y adaptabilidad en el diseño de clases y módulos. Este principio sostiene que el software debe estar diseñado de tal manera que se pueda expandir su funcionalidad sin necesidad de modificar el código existente. Esta característica es esencial no solo en clases y objetos individuales, sino también en servicios más amplios, microservicios y estructuras de casos de uso complejas.

En la práctica, el principio se implementa asegurando que las clases y módulos dependan de abstracciones (interfaces o clases abstractas) y no de implementaciones concretas. Por ejemplo, si consideramos diferentes tipos de empleados en una organización, como desarrolladores, personal de marketing y contables, y necesitamos calcular sus salarios, una aproximación que no cumple con este principio sería implementar un método específico para cada tipo de empleado. Sin embargo, esto resulta problemático y poco eficiente, ya que cualquier cambio en la lógica del cálculo de salarios implicaría modificar todas las implementaciones.

La solución que propone el Principio de Abierto/Cerrado es definir una interfaz o clase abstracta, por ejemplo, Salary. Las diferentes implementaciones, como SalaryOfDev, SalaryOfMark y SalaryOfCont, extenderían o implementarían esta interfaz, añadiendo su propia lógica específica para calcular el salario. Esta forma de estructurar el código significa que cualquier nuevo tipo de empleado solo requeriría una nueva implementación de Salary, sin necesidad de alterar la lógica existente en otras partes del sistema.

Además, es crucial que los casos de uso se acoplen solo a interfaces y no a implementaciones específicas. Esto se logra mediante la inyección de dependencias, donde, por ejemplo, se inyectaría la interfaz Salary en lugar de una implementación concreta (clase con métodos desarrollados). Esta práctica asegura que el sistema se mantiene flexible y abierto a la extensión, pero cerrado a cambios en sus componentes ya existentes.

Finalmente, es recomendable preferir la composición de clases y la inyección de dependencias sobre el uso de clases abstractas, excepto en situaciones donde las funcionalidades específicas y concretas de un modelo de dominio lo requieran. Esta preferencia se alinea con la programación orientada a eventos de dominio, como en CQRS (Command Query Responsibility Segregation), donde los eventos desencadenan acciones específicas. Por ejemplo, en un sistema donde el registro de un usuario es un evento, este podría desencadenar acciones como enviar un email de bienvenida o actualizar un contador de usuarios, cada una manejada por diferentes servicios. Este enfoque refuerza el principio al mantener el código separado y enfocado en responsabilidades únicas, mejorando así la mantenibilidad y escalabilidad del software.

Ejemplo sencillo

Spaghetti

/** Example whitout OCP principle*/
class SalaryCalculator
{
    public function calculateSalary($employeeType, $baseSalary) {
        switch ($employeeType) {
            case 'Developer':
                return $baseSalary * 1.2;
            case 'Marketing':
                return $baseSalary * 1.1;
            case 'Accounting':
                return $baseSalary * 1.3;
        }
    }
}

Cada vez que se añada un nuevo tipo de empleado, se debe la clase SalaryCalculator.

OCP

/** Example with OCP principle*/
interface SalaryCalculator
{
    public function calculateSalary($baseSalary);
}

class DeveloperSalaryCalculator implements SalaryCalculator
{
    public function calculateSalary($baseSalary) {
        return $baseSalary * 1.2;
    }
}

class MarketingSalaryCalculator implements SalaryCalculator
{
    public function calculateSalary($baseSalary) {
        return $baseSalary * 1.1;
    }
}

class AccountingSalaryCalculator implements SalaryCalculator
{
    public function calculateSalary($baseSalary) {
        return $baseSalary * 1.3;
    }
}

Cuando se necesite añadir un nuevo tipo de empleado, se crea una nueva clase que implemente SalaryCalculator, pero no se modifica ninguna clase existente ni la interfaz.

Para finalizar

---

Principios SOLID: Principio de Abierto/Cerrado OCP

El principio de abierto/cerrado, donde las entidades como clases deben estar cerradas para modificación pero abiertas para extensión.

#Video tutorial#hdeleon#SOLID