🔓 Open/Closed Principle (OCP) - Principio de Abierto/Cerrado

¿Qué es?

El Open/Closed Principle es uno de los cinco principios SOLID de la programación orientada a objetos. Este principio dice que las entidades de software (clases, módulos, funciones…) deben estar abiertas a la extensión pero cerradas a la modificación.

La frase original de Bertrand Meyer, que fue quien formuló este principio en 1988 en su libro “Object-Oriented Software Construction”, es:

“Software entities should be open for extension, but closed for modification.”

Esto quiere decir que para agregar funcionalidades nuevas deberías crear código nuevo sin tener que modificar el que ya está funcionando. Así reduces bastante la posibilidad de meter bugs al añadir cosas nuevas, porque el código existente queda intacto.

¿De dónde sale este principio?

El OCP tiene su origen en Bertrand Meyer, un ingeniero de software francés que lo formuló en 1988. Meyer es conocido por ser el creador del lenguaje de programación Eiffel (no se nota que es francés) y por su enfoque en el diseño por contrato (Design by Contract). En su visión original, la extensión se conseguía principalmente a través de la herencia de clases.

Sin embargo, fue Robert C. Martin (el tío Bob) quien lo adaptó al contexto de la POO moderna cuando recopiló los principios SOLID a finales de los 90 y principios de los 2000. Uncle Bob amplió la idea y puso el foco en el uso de abstracciones (interfaces y clases abstractas) como la forma principal de cumplir este principio. En lugar de depender exclusivamente de la herencia, se apuesta por la composición y el polimorfismo.

En su libro “Agile Software Development, Principles, Patterns, and Practices” (2002), Uncle Bob lo describe como uno de los principios fundamentales para crear software que escala sin convertirse en un monstruo de spaghetti code.

¿Qué significa “abierto” y “cerrado”?

---

¿Por qué es tan importante?

Aplicar el OCP te da ventajas muy claras en el día a día del desarrollo:

• Estabilidad: El código que ya funciona y está testeado no se toca. Menos cambios en código existente = menos bugs nuevos.
• Escalabilidad: Puedes añadir funcionalidades nuevas sin miedo. El sistema crece de forma controlada.
• Mantenibilidad: Las clases no se van inflando con condicionales infinitos. El código se mantiene limpio y enfocado.
• Testabilidad: Cada nueva funcionalidad se puede testear de forma aislada porque vive en su propia clase. No necesitas re-testear todo lo que ya funciona.
• Trabajo en equipo: Diferentes desarrolladores pueden añadir funcionalidades en paralelo sin machacarse el código mutuamente.

En el entorno profesional esto es importantísimo. Imagina un proyecto con 50 desarrolladores donde cada vez que alguien añade algo nuevo tiene que tocar una clase central que todo el mundo usa. Los conflictos en Git serían una pesadilla.

---

Ejemplo

Imagina que tenemos un carrito de la compra en la página y queremos vender un ebook. Para venderlo queremos ofrecer al usuario varias opciones de pago: Bizum, PayPal, tarjeta de crédito etc.

Tenemos la clase llamada PaymentProcessor que se va a encargar de esta tarea:

class PaymentProcessor {
    public function process($paymentMethod) {
        if ($paymentMethod === 'credit_card') {
            echo "Processing credit card payment";
        } elseif ($paymentMethod === 'paypal') {
            echo "Processing PayPal payment";
        } elseif ($paymentMethod === 'bizum') {
            echo "Processing Bizum payment";
        }
    }
}

En este código cada vez que queramos añadir un nuevo método de pago vamos a tener que abrir esta clase y meter un elseif más. ¿Que ahora quieres aceptar criptomonedas? Pues otro elseif. ¿Que mañana quieres Google Pay? Pos otro más. Esto inflige el principio de Abierto/Cerrado (OCP) porque estás modificando código existente cada vez que necesitas extender la funcionalidad.

Además, fíjate en los problemas que trae esto:

• Riesgo de liada: Cada cambio puede romper los métodos de pago que ya funcionaban.
• Clase inflada: Con el tiempo, esa clase se convierte en un monstruo con 30 condicionales.
• Difícil de testear: Cada test tiene que contemplar todos los caminos posibles.

Refactor

Para respetar el OCP haremos una refactorización usando una interfaz y polimorfismo:

interface PaymentMethod {
    public function processPayment(): void;
}

class CreditCardPayment implements PaymentMethod {
    public function processPayment(): void {
        echo "Processing credit card payment";
    }
}

class BizumPayment implements PaymentMethod {
    public function processPayment(): void {
        echo "Processing Bizum payment";
    }
}

class PayPalPayment implements PaymentMethod {
    public function processPayment(): void {
        echo "Processing PayPal payment";
    }
}

class PaymentProcessor {
    public function process(PaymentMethod $paymentMethod): void {
        $paymentMethod->processPayment();
    }
}

// Ejemplo de uso
$paymentProcessor = new PaymentProcessor();

$creditCardPayment = new CreditCardPayment();
$paymentProcessor->process($creditCardPayment);

$paypalPayment = new PayPalPayment();
$paymentProcessor->process($paypalPayment);

$bizumPayment = new BizumPayment();
$paymentProcessor->process($bizumPayment);

Ahora PaymentProcessor es tontito y ni sabe ni le importa qué método de pago le llega. Solo sabe que implementa PaymentMethod y que tiene un método processPayment(). Si mañana quieres aceptar criptomonedas, solo creas una clase nueva:

class CryptoPayment implements PaymentMethod {
    public function processPayment(): void {
        echo "Processing cryptocurrency payment";
    }
}

// Usarlo es inmediato, sin tocar NADA existente
$paymentProcessor->process(new CryptoPayment());

Cero modificaciones en el código existente. Abierto a extensión, cerrado a modificación.

---

Un ejemplo más real: sistema de notificaciones

El ejemplo del carrito es muy didáctico, pero vamos a ver uno más cercano al código del día a día. Imagina un sistema de notificaciones que envía alertas a los usuarios:

// MAL: violando el OCP
class NotificationService {
    public function send(string $type, string $message): void {
        if ($type === 'email') {
            // Configurar SMTP, enviar email...
            echo "Enviando email: $message";
        } elseif ($type === 'sms') {
            // Conectar con API de SMS...
            echo "Enviando SMS: $message";
        } elseif ($type === 'push') {
            // Conectar con servicio de push...
            echo "Enviando push notification: $message";
        } elseif ($type === 'telegram') {
            // Conectar con Bot API de Telegram...
            echo "Enviando por Telegram: $message";
        }
    }
}

Cada canal nuevo a añadir significa que vamos a tener que tocar esta clase. Y cada canal tiene su propia lógica de conexión, configuración, manejo de errores… Todo eso metido en un solo método. Menudo drama Pepe.

El refactor aplicando OCP:

interface NotificationChannel {
    public function send(string $message): void;
}

class EmailNotification implements NotificationChannel {
    public function send(string $message): void {
        // Configurar SMTP, enviar email...
        echo "Enviando email: $message";
    }
}

class SmsNotification implements NotificationChannel {
    public function send(string $message): void {
        // Conectar con API de SMS...
        echo "Enviando SMS: $message";
    }
}

class TelegramNotification implements NotificationChannel {
    public function send(string $message): void {
        // Conectar con Bot API de Telegram...
        echo "Enviando por Telegram: $message";
    }
}

class NotificationService {
    public function __construct(
        private NotificationChannel $channel
    ) {}

    public function notify(string $message): void {
        $this->channel->send($message);
    }
}

// Uso
$emailService = new NotificationService(new EmailNotification());
$emailService->notify("Tu pedido ha sido enviado");

$telegramService = new NotificationService(new TelegramNotification());
$telegramService->notify("Nuevo login detectado");

Ahora cada canal de notificación es independiente. Si mañana quieres enviar notificaciones por paloma mensajera, solo creas PalomaNotification y listo. El NotificationService ni se entera.

---

Otro ejemplo: exportación de reportes

Este es un caso que te vas a encontrar seguro. Imagina que tienes que exportar reportes en distintos formatos:

// MAL: la típica clase que crece sin parar
class ReportExporter {
    public function export(array $data, string $format): string {
        if ($format === 'pdf') {
            // 50 líneas generando PDF...
            return "PDF generado";
        } elseif ($format === 'csv') {
            // 30 líneas generando CSV...
            return "CSV generado";
        } elseif ($format === 'excel') {
            // 40 líneas generando Excel...
            return "Excel generado";
        }
        // ¿HTML? ¿JSON? ¿XML? ¿Markdown?... Esto no para de crecer
    }
}

La solución es la misma idea:

interface ReportFormatter {
    public function format(array $data): string;
}

class PdfFormatter implements ReportFormatter {
    public function format(array $data): string {
        // Lógica para generar PDF...
        return "PDF generado";
    }
}

class CsvFormatter implements ReportFormatter {
    public function format(array $data): string {
        // Lógica para generar CSV...
        return "CSV generado";
    }
}

class ExcelFormatter implements ReportFormatter {
    public function format(array $data): string {
        // Lógica para generar Excel...
        return "Excel generado";
    }
}

class ReportExporter {
    public function export(array $data, ReportFormatter $formatter): string {
        return $formatter->format($data);
    }
}

// Si mañana necesitas Markdown, solo creas:
class MarkdownFormatter implements ReportFormatter {
    public function format(array $data): string {
        return "Markdown generado";
    }
}

El OCP básicamente se reduce a: depende de abstracciones (interfaces) y usa polimorfismo. Así cada vez que necesites algo nuevo, creas una clase nueva que implemente la interfaz y el código existente ni se entera.

---

Relación con los patrones de diseño

El OCP está muy ligado a varios patrones de diseño que seguramente ya conozcas o te suenen. Estos patrones son herramientas que te ayudan a cumplir el principio de forma natural:

Si te fijas, todos estos patrones comparten la misma filosofía: nuevas funcionalidades = nuevas clases, no modificaciones en las existentes.

---

¿Cómo detectar que estás violando el OCP?

Para detectar incumplimientos del principio Open/Closed puedes fijarte en estas señales de alarma:

Uso excesivo de condicionales (if, else if, switch…)

Es la señal más clara. Si tienes una estructura con un if seguido de muchos elseif o un switch con 10 cases, es muy probable que estés violando el OCP. Cada vez que añadas una opción nueva vas a tener que abrir esa estructura y meter un caso más.

La clase sufre muchas modificaciones

Si en el historial de Git ves que una clase se modifica constantemente y por razones diferentes (hoy para añadir un método de pago, mañana para un formato de exportación), es una señal clara.

Clases con múltiples tipos de comportamiento

Por ejemplo, una clase que exporta reportes en varios formatos en un solo método (PDF, CSV, HTML, Markdown…) o una clase que maneja distintos tipos de usuarios con lógica diferente según el tipo.

Dependencias de tipos concretos en lugar de abstractos

Si tu código depende directamente de BizumPayment en lugar de PaymentMethod, estás acoplado a una implementación concreta. Cuando necesites cambiar o añadir algo, tendrás que modificar ese código.

Incumplimiento del Principio de Sustitución de Liskov (LSP)

El OCP y el LSP están muy relacionados. Si no puedes sustituir una clase hija por su clase base sin que las cosas se rompan, es bastante probable que también estés violando el OCP. Ambos principios se refuerzan mutuamente.

Si es complicado agregar funcionalidades sin modificar código existente

Esta es la prueba definitiva. Si cada vez que necesitas algo nuevo tienes que tocar código que ya funciona, algo no está bien diseñado. Lo ideal es que una funcionalidad nueva signifique crear código, no modificar código.

No se usan patrones de diseño adecuados

No usar los patrones Strategy, State, Factory o Decorator cuando la situación lo pide puede ser una pista de que no se está respetando el OCP. Estos patrones son herramientas diseñadas precisamente para añadir funcionalidades sin tocar lo existente.

---

Errores comunes al aplicar el OCP

Como con todos los principios SOLID, aplicar el OCP también tiene sus trampas. Aquí van los errores más habituales:

• Sobre-abstraer desde el principio: No necesitas crear una interfaz para todo desde el día 1. Si solo tienes un método de pago, no hace falta montar toda la arquitectura de interfaces. Refactoriza cuando aparezca la segunda variante, no antes. Esto se conoce como la “regla de los tres”: cuando algo se repite tres veces, abstráelo.
• Crear abstracciones que nunca se extienden: Si creas una interfaz con una sola implementación y nunca llega la segunda, has añadido complejidad gratis. Las abstracciones deben justificarse con uso real, no con especulaciones de futuro.
• Olvidar que el OCP aplica a todos los niveles: No es solo para clases. También aplica a funciones, módulos, paquetes e incluso arquitecturas completas. Una API REST bien diseñada, por ejemplo, debería permitir añadir endpoints nuevos sin modificar los existentes.
• Confundir extensión con herencia: Extender no siempre significa heredar. La composición y la inyección de dependencias son formas igual de válidas (y muchas veces mejores) de extender funcionalidades.
• No cerrar lo que debería estar cerrado: A veces por prisas se deja una clase “abierta a todo” sin ningún contrato claro. Si cualquiera puede modificar cualquier cosa, no hay OCP que valga.

---

¿Cuándo NO aplicar el OCP?

Igual que con el resto de principios SOLID, el OCP no es una ley universal. Hay situaciones donde forzarlo es peor que el problema:

• Código que no va a cambiar: Si tienes un script de migración que se ejecuta una vez o un módulo que llevas 3 años sin tocar, no necesitas abstraerlo.
• Prototipos y MVPs: Cuando estás validando una idea, la velocidad importa más que la arquitectura. Ya refactorizarás si la idea funciona.
• Lógica simple con pocas variantes: Si tu if/else tiene dos casos y es improbable que crezca, meter una interfaz con dos implementaciones es matar mosquitos a cañonazos.
• Cuando la abstracción es más confusa que el código original: Si para entender el flujo hay que saltar por 7 archivos y 4 interfaces, quizá un switch bien documentado es más claro y mantenible.

Recuerda: El OCP es una herramienta, no una religión. Aplícalo cuando aporte valor real, no por cumplir un checklist.

---

Relación con otros principios SOLID

El OCP no vive solo. Está conectado con el resto de principios SOLID y se refuerzan mutuamente:

• SRP (Responsabilidad Única): Si cada clase tiene una sola responsabilidad, es más fácil extenderla sin tocar otras cosas. El SRP facilita el OCP.
• LSP (Sustitución de Liskov): Para que la extensión funcione correctamente, las clases hijas deben poder sustituir a sus padres sin romper nada. Sin LSP, el OCP se desmorona.
• ISP (Segregación de Interfaces): Interfaces pequeñas y específicas hacen que las extensiones sean más limpias. No te obligan a implementar cosas que no necesitas.
• DIP (Inversión de Dependencias): Depender de abstracciones en lugar de implementaciones concretas es la base técnica del OCP. Sin DIP, cerrar una clase a la modificación es prácticamente imposible.

Es muy difícil cumplir el OCP si no cumples los demás. Por eso los principios SOLID funcionan como un equipo: cada uno aporta su parte para que el conjunto sea sólido (nunca mejor dicho).

---

Conclusión

El Principio Abierto/Cerrado es uno de los pilares más potentes de SOLID. Su idea central es sencilla pero poderosa: diseña tu código de forma que puedas añadir cosas nuevas sin tocar lo que ya funciona.

La clave técnica es usar abstracciones (interfaces, clases abstractas) y polimorfismo para que el código existente trabaje con contratos, no con implementaciones concretas. Así, cada extensión es una clase nueva que cumple un contrato, sin necesidad de modificar nada.

No te obsesiones con aplicarlo desde el primer momento. Deja que el código te pida la abstracción cuando la necesite.

Espero que se haya entendido ejeejjeje EA nos beermos! 🍻

---

Pon a prueba lo aprendido