Principios SOLID en PHP: guía completa con ejemplos de código

Introducción: por qué SOLID es la base del código PHP de calidad

Cada desarrollador PHP, tarde o temprano, se enfrenta al problema del "código espagueti": las clases se vuelven sobrecargadas, los cambios en un lugar rompen toda la aplicación y las pruebas se convierten en una pesadilla. La solución a este problema son los principios SOLID. Desarrollados por Robert Martin (Tío Bob), estos cinco principios de la programación orientada a objetos ayudan a crear código flexible, mantenible y escalable.

En este artículo, analizaremos cada uno de los cinco principios SOLID con ejemplos prácticos en PHP. Aprenderá cómo aplicarlos en proyectos reales y verá la diferencia entre el código "malo" y el "bueno". El material es adecuado tanto para principiantes como para desarrolladores experimentados que deseen sistematizar sus conocimientos.

1. Single Responsibility Principle (SRP) — Principio de Responsabilidad Única

Esencia del principio

Una clase debe tener una sola razón para cambiar. Esto significa que cada módulo o clase es responsable de una tarea específica.

Ejemplo incorrecto (violación de SRP)

<?php\nclass Report {\n    public function generateReport($data) {\n        // Generación de datos del informe\n        $report = "Informe: " . json_encode($data);\n\n        // Guardar en archivo\n        file_put_contents('report.txt', $report);\n\n        // Enviar por correo electrónico\n        mail('admin@example.com', 'Nuevo informe', $report);\n\n        return $report;\n    }\n}\n?>

Aquí la clase Report hace tres cosas diferentes: genera el informe, lo guarda y lo envía. Un cambio en la lógica de envío de correo electrónico romperá la generación del informe.

Ejemplo correcto (cumplimiento de SRP)

<?php\nclass ReportGenerator {\n    public function generate(array $data): string {\n        return "Informe: " . json_encode($data);\n    }\n}\n\nclass ReportSaver {\n    public function save(string $report, string $filename): void {\n        file_put_contents($filename, $report);\n    }\n}\n\nclass ReportMailer {\n    public function send(string $report, string $email): void {\n        mail($email, 'Nuevo informe', $report);\n    }\n}\n\n// Uso\n$generator = new ReportGenerator();\n$report = $generator->generate($data);\n\n$saver = new ReportSaver();\n$saver->save($report, 'report.txt');\n\n$mailer = new ReportMailer();\n$mailer->send($report, 'admin@example.com');\n?>

Ahora cada clase tiene una única responsabilidad, y cambiar la forma de guardar no afectará al envío del correo electrónico.

2. Open/Closed Principle (OCP) — Principio de Abierto/Cerrado

Esencia del principio

Las entidades de software deben estar abiertas para la extensión, pero cerradas para la modificación. En otras palabras, debe poder agregar nueva funcionalidad sin cambiar el código existente.

Ejemplo incorrecto (violación de OCP)

<?php\nclass PaymentProcessor {\n    public function process($type, $amount) {\n        if ($type === 'credit_card') {\n            // Procesamiento de tarjeta de crédito\n        } elseif ($type === 'paypal') {\n            // Procesamiento de PayPal\n        } elseif ($type === 'bitcoin') {\n            // Procesamiento de Bitcoin\n        }\n        // ¡Cada nuevo tipo de pago requiere modificar este método!\n    }\n}\n?>

Ejemplo correcto (cumplimiento de OCP)

<?php\ninterface PaymentMethod {\n    public function process(float $amount): bool;\n}\n\nclass CreditCardPayment implements PaymentMethod {\n    public function process(float $amount): bool {\n        // Lógica de pago con tarjeta de crédito\n        echo "Pago con tarjeta: $amount\\n";\n        return true;\n    }\n}\n\nclass PayPalPayment implements PaymentMethod {\n    public function process(float $amount): bool {\n        // Lógica de pago con PayPal\n        echo "Pago PayPal: $amount\\n";\n        return true;\n    }\n}\n\nclass BitcoinPayment implements PaymentMethod {\n    public function process(float $amount): b