Principios SOLID en C++: de la teoría a la práctica para código limpio

Introducción: ¿Por qué SOLID es importante para el desarrollador de C++?

SOLID es el acrónimo de cinco principios fundamentales de la programación orientada a objetos, formulados por Robert Martin (Tío Bob). Para el desarrollador de C++, estos principios no son solo teoría abstracta, sino una herramienta práctica que ayuda a crear aplicaciones flexibles, mantenibles y comprobables. En el mundo de C++, donde la gestión de memoria y el rendimiento son críticos, seguir SOLID permite evitar el "código espagueti" y simplifica la refactorización.

En este artículo, analizaremos cada principio SOLID con ejemplos concretos en C++. Verá cómo la violación de los principios genera problemas y cómo solucionarlos. Usaremos C++ moderno (C++11/14/17/20) para que los ejemplos sean relevantes.

1. Single Responsibility Principle (SRP) — Principio de responsabilidad única

Esencia del principio

Una clase debe tener solo una razón para cambiar. En otras palabras, cada clase es responsable de una sola funcionalidad o aspecto del sistema.

Violación de SRP en C++

Considere una clase que viola SRP: gestiona simultáneamente los datos de un informe y su formato.

class Report {\npublic:\n    void generateReport(const std::vector<Data>& data) {\n        // Lógica de procesamiento de datos\n        m_data = data;\n    }\n    \n    void saveToFile(const std::string& filename) {\n        // Lógica de guardado en archivo\n        std::ofstream file(filename);\n        for (const auto& item : m_data) {\n            file << item.toString() << "\\n";\n        }\n    }\n    \n    void printToConsole() {\n        // Lógica de salida a consola\n        for (const auto& item : m_data) {\n            std::cout << item.toString() << std::endl;\n        }\n    }\n    \nprivate:\n    std::vector<Data> m_data;\n};

Problema: si cambia el formato de salida, habrá que modificar la clase Report. Si cambia la forma de almacenar los datos, también. Esto viola SRP.

Corrección: separamos responsabilidades

// Solo responsable de los datos del informe\nclass ReportData {\npublic:\n    void addData(const Data& item) {\n        m_data.push_back(item);\n    }\n    \n    const std::vector<Data>& getData() const {\n        return m_data;\n    }\n    \nprivate:\n    std::vector<Data> m_data;\n};\n\n// Solo responsable de guardar\nclass FileSaver {\npublic:\n    void save(const std::string& filename, const ReportData& report) {\n        std::ofstream file(filename);\n        for (const auto& item : report.getData()) {\n            file << item.toString() << "\\n";\n        }\n    }\n};\n\n// Solo responsable de la salida a consola\nclass ConsolePrinter {\npublic:\n    void print(const ReportData& report) {\n        for (const auto& item : report.getData()) {\n            std::cout << item.toString() << std::endl;\n        }\n    }\n};

Ahora cada clase tiene una sola razón para cambiar, lo que hace que el código sea más flexible y fácil de probar.

2. Open-Closed Principle (OCP) — Principio de abierto/cerrado

Esencia del principio

Las entidades de software (clases, módulos, funciones) deben estar abiertas para extensión, pero cerradas para modificación. Esto significa que debe poder agregar nueva funcionalidad sin modificar el código existente.

Violación de OCP en C++

Imagine un sistema de cálculo de descuentos donde se usa if-else para cada tipo de cliente.

class DiscountCalculator {\npublic:\n    double calculateDiscount(const std::string& customerType, double amount) {\n        if (customerType == "regular") {\n            return amount * 0.1; // 10%\n        } else if (customerType == "vip") {\n            return amount * 0.2; // 20%\n        } else if (customerType == "premium") {\n            return amount * 0.3; // 30%\n        }\n