Principio abierto/cerrado

Introducción

El Principio Abierto-Cerrado (OCP, por sus siglas en inglés) es uno de los principios SOLID de diseño de software orientado a objetos. Fue acuñado en 1988 por Bertrand Meyer y establece que:

Un artefacto de software debe estar abierto para su extensión, pero cerrado para su modificación.

En otras palabras, el comportamiento de un artefacto de software debe poder extenderse sin tener que modificar el artefacto en sí. Este principio es fundamental en la arquitectura de software y tiene implicaciones significativas tanto a nivel de clases y módulos como a nivel de componentes arquitectónicos.

Importancia del OCP

El OCP es crucial por las siguientes razones:

1. Flexibilidad: Permite agregar nuevas funcionalidades sin alterar el código existente.
2. Mantenibilidad: Reduce el riesgo de introducir errores en código que ya funciona.
3. Escalabilidad: Facilita el crecimiento y evolución del sistema a lo largo del tiempo.

Si un sistema no sigue el OCP, pequeños cambios en los requisitos podrían forzar modificaciones masivas en el software, lo que indicaría un fallo significativo en su arquitectura.

Un experimento mental

Para entender mejor la aplicación del OCP a nivel arquitectónico, consideremos el siguiente escenario:

Imaginemos que tenemos un sistema en Java que muestra un resumen contable en una página web. Los datos son desplazables y los números negativos se muestran en rojo. Ahora, los interesados solicitan que esta misma información se convierta en un informe para imprimir en una impresora en blanco y negro. El informe debe estar correctamente paginado, con encabezados y pies de página apropiados, y etiquetas de columna. Los números negativos deben estar entre paréntesis.

La pregunta clave es: ¿cuánto código existente tendrá que cambiar para implementar esta nueva funcionalidad?

Una buena arquitectura de software reduciría la cantidad de código modificado al mínimo absoluto, idealmente a cero. ¿Cómo se logra esto? Aplicando dos principios fundamentales:

1. El Principio de Responsabilidad Única (SRP): Separando las cosas que cambian por diferentes razones (visto anteriormente).
2. El Principio Abierto-Cerrado (OCP): Organizando el código de manera que sea extensible sin necesidad de modificación.

Aplicación práctica en Java

Veamos cómo podemos aplicar el OCP para diseñar una arquitectura flexible y extensible en Java.

Paso 1: Separación de responsabilidades (SRP)

Aplicando el Principio de Responsabilidad Única (SRP), podemos identificar dos responsabilidades principales en nuestro sistema:

1. El cálculo de los datos financieros.
2. La presentación de esos datos en diferentes formatos (web e impreso).

Esta separación nos permite crear un flujo de datos como el siguiente:

[Datos Financieros] -> [Análisis] -> [Datos Reportables] -> [Formato Web]
                                                         -> [Formato Impreso]

Paso 2: Implementación de la arquitectura (OCP)

Veamos cómo podría ser la implementación de esta arquitectura en Java:

// Interfaces
interface FinancialDataGateway {
    List<FinancialData> getFinancialData();
}

interface FinancialReportPresenter {
    String present(List<FinancialData> data);
}

// Clase de datos
class FinancialData {
    // Atributos y métodos...
}

// Interactor
class FinancialReportGenerator {
    private final FinancialDataGateway dataGateway;

    public FinancialReportGenerator(FinancialDataGateway dataGateway) {
        this.dataGateway = dataGateway;
    }

    public List<FinancialData> generateReport() {
        List<FinancialData> data = dataGateway.getFinancialData();
        // Procesar datos...
        return processedData;
    }
}

// Presentadores
class WebPresenter implements FinancialReportPresenter {
    @Override
    public String present(List<FinancialData> data) {
        // Formatear datos para web
        return webFormattedData;
    }
}

class PrintPresenter implements FinancialReportPresenter {
    @Override
    public String present(List<FinancialData> data) {
        // Formatear datos para impresión
        return printFormattedData;
    }
}

// Controlador
class FinancialReportController {
    private final FinancialReportGenerator generator;
    private final FinancialReportPresenter presenter;

    public FinancialReportController(FinancialReportGenerator generator, FinancialReportPresenter presenter) {
        this.generator = generator;
        this.presenter = presenter;
    }

    public String createReport() {
        List<FinancialData> data = generator.generateReport();
        return presenter.present(data);
    }
}

// Uso
public class Main {
    public static void main(String[] args) {
        FinancialDataGateway dataGateway = new ConcreteFinancialDataGateway();
        FinancialReportGenerator generator = new FinancialReportGenerator(dataGateway);

        FinancialReportPresenter webPresenter = new WebPresenter();
        FinancialReportController webController = new FinancialReportController(generator, webPresenter);
        String webReport = webController.createReport();

        FinancialReportPresenter printPresenter = new PrintPresenter();
        FinancialReportController printController = new FinancialReportController(generator, printPresenter);
        String printReport = printController.createReport();
    }
}

Análisis de la implementación

1. Extensibilidad: Para añadir un nuevo formato de reporte (por ejemplo, PDF), solo necesitamos crear una nueva clase PDFPresenter que implemente FinancialReportPresenter. No se requiere modificar el código existente.

2. Separación de responsabilidades: Cada clase tiene una única responsabilidad. Por ejemplo, FinancialReportGenerator se encarga solo de generar los datos del reporte, mientras que los presentadores se encargan únicamente de formatear esos datos.

3. Protección de componentes: El FinancialReportGenerator está protegido de los cambios en los componentes de presentación. Puede generar reportes sin saber cómo se presentarán.

Esta implementación permite que nuestro sistema sea abierto para la extensión (podemos añadir nuevos formatos de presentación) pero cerrado para la modificación (no necesitamos cambiar el código existente para añadir estas nuevas funcionalidades).

Ejemplo de aplicación: Sistema de Gestión de Empleados

Imaginemos que estamos desarrollando un sistema de gestión de empleados para una empresa. Inicialmente, el sistema calcula los salarios de los empleados regulares. Sin embargo, la empresa está creciendo y ahora necesita manejar diferentes tipos de empleados, cada uno con su propio cálculo de salario.

Versión inicial (sin OCP)

Primero, veamos cómo podría verse una implementación que no sigue el OCP:

public class Empleado {
    private String nombre;
    private String tipo;  // "regular", "contratista", "gerente", "supervisor", etc.
    private double salarioBase;

    public Empleado(String nombre, String tipo, double salarioBase) {
        this.nombre = nombre;
        this.tipo = tipo;
        this.salarioBase = salarioBase;
    }

    public double calcularSalario() {
        if (tipo.equals("regular")) {
            return salarioBase;
        } else if (tipo.equals("contratista")) {
            return salarioBase * 1.5;
        } else if (tipo.equals("gerente")) {
            return salarioBase * 2 + 1000;
        } else if (tipo.equals("supervisor")) {
            return salarioBase * 1.8;
        } else {

        throw new IllegalArgumentException("Tipo de empleado desconocido");
    }

    // Getters y setters...
}

public class CalculadoraNomina {
    public double calcularNominaTotalMensual(List<Empleado> empleados) {
        double total = 0;
        for (Empleado empleado : empleados) {
            total += empleado.calcularSalario();
        }
        return total;
    }
}

Esta implementación viola el OCP porque cada vez que se añade un nuevo tipo de empleado, necesitamos modificar la clase Empleado y su método calcularSalario().

Aplicando el OCP

Ahora, veamos cómo podemos rediseñar este sistema aplicando el OCP:

// Interfaz para el cálculo de salario
public interface CalculadoraSalario {
    double calcularSalario(double salarioBase);
}

// Implementaciones concretas para cada tipo de empleado
public class CalculadoraSalarioRegular implements CalculadoraSalario {
    @Override
    public double calcularSalario(double salarioBase) {
        return salarioBase;
    }
}

public class CalculadoraSalarioContratista implements CalculadoraSalario {
    @Override
    public double calcularSalario(double salarioBase) {
        return salarioBase * 1.5;
    }
}

public class CalculadoraSalarioGerente implements CalculadoraSalario {
    @Override
    public double calcularSalario(double salarioBase) {
        return salarioBase * 2 + 1000;
    }
}

// Clase Empleado refactorizada
public class Empleado {
    private String nombre;
    private double salarioBase;
    private CalculadoraSalario calculadoraSalario;

    public Empleado(String nombre, double salarioBase, CalculadoraSalario calculadoraSalario) {
        this.nombre = nombre;
        this.salarioBase = salarioBase;
        this.calculadoraSalario = calculadoraSalario;
    }

    public double calcularSalario() {
        return calculadoraSalario.calcularSalario(salarioBase);
    }

    // Getters y setters...
}

// La clase CalculadoraNomina no necesita modificaciones
public class CalculadoraNomina {
    public double calcularNominaTotalMensual(List<Empleado> empleados) {
        double total = 0;
        for (Empleado empleado : empleados) {
            total += empleado.calcularSalario();
        }
        return total;
    }
}

Mejoras realizadas

1. Extensibilidad: Ahora podemos añadir nuevos tipos de empleados sin modificar las clases existentes. Por ejemplo, si queremos añadir un tipo de empleado “Ejecutivo”:

   public class CalculadoraSalarioEjecutivo implements CalculadoraSalario {
       @Override
       public double calcularSalario(double salarioBase) {
           return salarioBase * 3 + 2000;
       }
   }

   No necesitamos modificar Empleado, CalculadoraNomina, ni ninguna otra clase existente.

2. Flexibilidad: Podemos cambiar fácilmente el cálculo del salario para un empleado en tiempo de ejecución:

   Empleado juan = new Empleado("Juan", 3000, new CalculadoraSalarioRegular());
   // Más adelante...
   juan.setCalculadoraSalario(new CalculadoraSalarioGerente());

3. Mantenibilidad: Cada tipo de cálculo de salario está encapsulado en su propia clase, lo que hace que el código sea más fácil de mantener y probar.

4. Principio de Responsabilidad Única (SRP): Cada clase tiene una única razón para cambiar. Por ejemplo, CalculadoraSalarioContratista solo cambiará si la fórmula para calcular el salario de los contratistas cambia.

Uso del sistema

public class SistemaGestionEmpleados {
    public static void main(String[] args) {
        List<Empleado> empleados = new ArrayList<>();
        empleados.add(new Empleado("María", 3000, new CalculadoraSalarioRegular()));
        empleados.add(new Empleado("Carlos", 4000, new CalculadoraSalarioContratista()));
        empleados.add(new Empleado("Ana", 5000, new CalculadoraSalarioGerente()));

        CalculadoraNomina calculadora = new CalculadoraNomina();
        double nominaTotal = calculadora.calcularNominaTotalMensual(empleados);

        System.out.println("La nómina total mensual es: " + nominaTotal);
    }
}

Conclusiones del ejemplo

Este ejemplo demuestra cómo la aplicación del OCP nos permite crear un sistema que es fácilmente extensible. Podemos añadir nuevos tipos de empleados y cálculos de salario sin modificar el código existente, simplemente creando nuevas clases que implementen la interfaz CalculadoraSalario.

Además, esta estructura facilita la aplicación de otros principios SOLID, como el Principio de Responsabilidad Única (SRP), lo que resulta en un diseño más robusto y mantenible.

Conclusión

El Principio Abierto-Cerrado nos permite diseñar sistemas flexibles y fáciles de mantener. Al separar las responsabilidades y utilizar interfaces, podemos crear una arquitectura que sea resistente a los cambios y fácil de extender. En nuestro primer ejemplo, podemos agregar nuevos formatos de presentación sin modificar el código existente, cumpliendo así con el OCP.

La aplicación del OCP en Java nos permite crear sistemas más modulares y menos propensos a errores, facilitando el mantenimiento y la evolución del software a lo largo del tiempo.