En el desarrollo de software, el mantenimiento, la extensión y la flexibilidad del código son importantes para el éxito a largo plazo de un proyecto. Los principios SOLID se formularon para guiar a los desarrolladores en la creación de código que sea más fácil de entender, modificar y ampliar. En este artículo, hablaremos sobre cada uno de los cinco principios SOLID y cómo usarlos con ejemplos prácticos en Java.

1. Principio de responsabilidad única

El Principio de Responsabilidad Única (SRP) establece que una clase debe tener un solo motivo para cambiar, es decir, debe tener una única responsabilidad dentro del sistema.

// Antes de aplicar o SRP
class ProductService {
    public void saveProduct(Product product) {
        // Lógica para salvar o produto no banco de dados
    }

    public void sendEmail(Product product) {
        // Lógica para enviar um email sobre o produto
    }
}

// Após aplicar o SRP
class ProductService {
    public void saveProduct(Product product) {
        // Lógica para salvar o produto no banco de dados
    }
}

class EmailService {
    public void sendEmail(Product product) {
        // Lógica para enviar um email sobre o produto
    }
}

En el ejemplo, separamos la responsabilidad de guardar un producto en la base de datos de la responsabilidad de enviar correos electrónicos sobre el producto. Esto facilita cambios futuros, ya que los cambios en el envío de correos electrónicos ya no afectan la lógica de guardado del producto.

2. Principio abierto/cerrado

El principio abierto/cerrado (OCP) sugiere que las entidades de software (clases, módulos, funciones, etc.) deben estar abiertas a la extensión, pero cerradas a la modificación. Esto se logra mediante el uso de abstracciones y herencia.

// Exemplo inicial violando o OCP
class AreaCalculator {
    public double calculateArea(Rectangle[] rectangles) {
        double area = 0;
        for (Rectangle rectangle : rectangles) {
            area  = rectangle.width * rectangle.height;
        }
        return area;
    }
}

// Exemplo após aplicar o OCP
interface Forma {
    double calculateArea();
}
class Rectangle implements Forma {
    private double width;
    private double height;

    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }
    @Override
    public double calculateArea() {
        return width * height;
    }
}

class AreaCalculator {
    public double calculateArea(Forma [] formas) {
        double area = 0;
        for (Forma formas: formas) {
            area  = forma.calculateArea();
        }
        return area;
    }
}

En este segundo ejemplo, inicialmente la clase AreaCalculator dependía directamente de la clase Rectángulo. Esto significa que si quisieras agregar otro tipo de forma, como un círculo o un triángulo, necesitarías modificar la clase AreaCalculator, violando así el OCP. Con la creación de la interfaz Shape, la clase AreaCalculator es capaz de recibir nuevas formas geométricas sin modificar el código existente.

3. Principio de sustitución de Liskov

El Principio de Sustitución de Liskov (LSP) establece que los objetos de una superclase deben ser reemplazables por objetos de sus subclases sin afectar la integridad del sistema. En otras palabras, el comportamiento de las subclases debe ser consistente con el comportamiento de las superclases.

// Classe base
class Bird {
    public void fly() {
        // Método padrão que imprime "Flying"
        System.out.println("Flying");
    }
}

// Classe derivada que viola o LSP
class Duck extends Bird {
    @Override
    public void fly() {
        // Sobrescrita que imprime "Ducks cannot fly"
        System.out.println("Ducks cannot fly");
    }
}

Problema: La clase Duck está anulando el método fly() para imprimir "Los patos no pueden volar", cambiando así el comportamiento predeterminado definido en la clase base Bird, que es que todos los pájaros vuelan ("Volando"). Esto viola el LSP porque cualquier código que espere que un objeto Bird o sus subclases vuele no funcionará correctamente con un Duck, que ya sabemos que no vuela.

// Classe derivada que respeita o LSP
interface Bird {
    void fly();
}
class Eagle implements Bird {
    @Override
    public void fly() {
        System.out.println("Flying like an Eagle");
    }
}
class Duck implements Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException("Ducks cannot fly");
    }
}

Con este enfoque, Eagle y Duck pueden ser intercambiables donde se espera un Bird, sin romper las expectativas establecidas por la interfaz Bird. La excepción lanzada por Duck comunica explícitamente que los patos no vuelan, sin modificar el comportamiento de la superclase de una manera que pueda causar problemas inesperados en el código.

4. Principio de segregación de interfaz

El principio de segregación de interfaces (ISP) sugiere que las interfaces de una clase deben ser específicas para los clientes que las utilizan. Esto evita interfaces "gordas" que requieren implementaciones de métodos no utilizados por los clientes.

// Exemplo antes de aplicar o ISP
interface Worker {
    void work();
    void eat();
    void sleep();
}

class Programmer implements Worker {
    @Override
    public void work() {
        // Lógica específica para programar
    }
    @Override
    public void eat() {
        // Lógica para comer
    }
    @Override
    public void sleep() {
        // Lógica para dormir
    }
}

// Exemplo após aplicar o ISP
interface Worker {
    void work();
}
interface Eater {
    void eat();
}
interface Sleeper {
    void sleep();
}
class Programmer implements Worker, Eater, Sleeper {
    @Override
    public void work() {
        // Lógica específica para programar
    }
    @Override
    public void eat() {
        // Lógica para comer
    }
    @Override
    public void sleep() {
        // Lógica para dormir
    }
}

En el ejemplo, dividimos la interfaz Worker en interfaces más pequeñas (Work, Eat, Sleep) para garantizar que las clases que las implementan tengan solo los métodos que necesitan. Esto evita que las clases tengan que implementar métodos que no son relevantes para ellas, lo que mejora la claridad y la cohesión del código.

5. Principio de inversión de dependencia

El Principio de Inversión de Dependencia (DIP) sugiere que los módulos de alto nivel (como clases de negocios o aplicaciones, que implementan las principales reglas de negocios) no deberían depender de módulos de bajo nivel (clases de infraestructura, como el acceso a datos externos y servicios que apoyan operaciones de alto nivel). Ambos deben depender de abstracciones.

// Exemplo antes de aplicar o DIP
class BackendDeveloper {
    public void writeJava() {
        // Lógica para escrever em Java
    }
}
class Project {
    private BackendDeveloper developer;

    public Project() {
        this.developer = new BackendDeveloper();
    }
    public void implement() {
        developer.writeJava();
    }
}

// Exemplo após aplicar o DIP
interface Developer {
    void develop();
}
class BackendDeveloper implements Developer {
    @Override
    public void develop() {
        // Lógica para escrever em Java
    }
}
class Project {
    private Developer developer;

    public Project(Developer developer) {
        this.developer = developer;
    }
    public void implement() {
        developer.develop();
    }
}

La clase Proyecto ahora depende de una abstracción (Desarrollador) en lugar de una implementación concreta (BackendDeveloper). Esto permite inyectar fácilmente diferentes tipos de desarrolladores (por ejemplo, FrontendDeveloper, MobileDeveloper) en la clase Proyecto sin modificar su código.

Conclusión

Adoptar principios SÓLIDOS no solo aumenta la calidad de su código, sino que también fortalece sus habilidades técnicas, aumenta la eficiencia de su trabajo e impulsa su trayectoria profesional como desarrollador de software.