SOLID Oriented Development

In software development, code maintenance, extension and flexibility are important for the long-term success of a project. The SOLID principles were formulated to guide developers in creating code that is easier to understand, modify, and extend. In this article, we will talk about each of the five SOLID principles and how to use them with practical examples in Java.

1. Single Responsibility Principle

The Single Responsibility Principle (SRP) establishes that a class must have only one reason to change, that is, it must have a single responsibility within the system.

// 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
    }
}

In the example, we separate the responsibility for saving a product in the database from the responsibility for sending emails about the product. This facilitates future changes, as changes in sending emails no longer affect the product saving logic.

2. Open/Closed Principle

The Open/Closed Principle (OCP) suggests that software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. This is achieved through the use of abstractions and inheritance.

// 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;
    }
}

In this second example, initially the AreaCalculator class was directly dependent on the Rectangle class. This means that if you wanted to add another type of shape, like a circle or a triangle, you would need to modify the AreaCalculator class, thus violating OCP. With the creation of the Shape interface, the AreaCalculator class is capable of receiving new geometric shapes without modifying the existing code.

3. Liskov Substitution Principle

The Liskov Substitution Principle (LSP) states that objects of a superclass must be replaceable by objects of its subclasses without affecting the integrity of the system. In other words, the behavior of subclasses must be consistent with the behavior of superclasses.

// 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");
    }
}

Problem: The Duck class is overriding the fly() method to print "Ducks cannot fly", so we change the default behavior defined in the Bird base class, which is that all birds fly ("Flying"). This violates LSP because any code that expects a Bird object or its subclasses to fly will not work correctly with a Duck, which we already know doesn't fly.

// 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");
    }
}

With this approach, Eagle and Duck can be interchangeable where a Bird is expected, without breaking the expectations set by the Bird interface. The exception thrown by Duck explicitly communicates that ducks don't fly, without modifying the superclass's behavior in a way that could cause unexpected problems in the code.

4. Interface Segregation Principle

The Interface Segregation Principle (ISP) suggests that the interfaces of a class should be specific to the clients that use them. This avoids "fat" interfaces that require implementations of methods not used by clients.

// 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
    }
}

In the example, we split the Worker interface into smaller interfaces (Work, Eat, Sleep) to ensure that the classes that implement them have only the methods they need. This prevents classes from having to implement methods that are not relevant to them, improving code clarity and cohesion.

5. Dependency Inversion Principle

The Dependency Inversion Principle (DIP) suggests that high-level modules (such as business or application classes, which implement the main business rules) should not depend on low-level modules (infrastructure classes, such as access to external data and services that support high-level operations). Both must depend on abstractions.

// 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();
    }
}

The Project class now depends on an abstraction (Developer) instead of a concrete implementation (BackendDeveloper). This allows different types of developers (e.g. FrontendDeveloper, MobileDeveloper) to be easily injected into the Project class without modifying its code.

Conclusion

Adopting SOLID principles not only raises the quality of your code, it also strengthens your technical skills, increases your work efficiency, and boosts your career path as a software developer.

The above is the detailed content of SOLID Oriented Development. For more information, please follow other related articles on the PHP Chinese website!