Développement orienté SOLIDE

Dans le développement de logiciels, la maintenance, l'extension et la flexibilité du code sont importantes pour le succès à long terme d'un projet. Les principes SOLID ont été formulés pour guider les développeurs dans la création d'un code plus facile à comprendre, à modifier et à étendre. Dans cet article, nous parlerons de chacun des cinq principes SOLID et de la manière de les utiliser avec des exemples pratiques en Java.

1. Principe de responsabilité unique

Le principe de responsabilité unique (SRP) établit qu'une classe ne doit avoir qu'une seule raison de changer, c'est-à-dire qu'elle doit avoir une seule responsabilité au sein du système.

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

Dans l'exemple, nous séparons la responsabilité de sauvegarder un produit dans la base de données de la responsabilité d'envoyer des e-mails concernant le produit. Cela facilite les changements futurs, car les changements dans l'envoi d'e-mails n'affectent plus la logique de sauvegarde du produit.

2. Principe ouvert/fermé

Le principe ouvert/fermé (OCP) suggère que les entités logicielles (classes, modules, fonctions, etc.) doivent être ouvertes pour extension, mais fermées pour modification. Ceci est réalisé grâce à l'utilisation d'abstractions et d'héritage.

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

Dans ce deuxième exemple, initialement la classe AreaCalculator dépendait directement de la classe Rectangle. Cela signifie que si vous souhaitez ajouter un autre type de forme, comme un cercle ou un triangle, vous devrez modifier la classe AreaCalculator, violant ainsi OCP. Avec la création de l'interface Shape, la classe AreaCalculator est capable de recevoir de nouvelles formes géométriques sans modifier le code existant.

3. Principe de substitution de Liskov

Le principe de substitution de Liskov (LSP) stipule que les objets d'une superclasse doivent être remplacés par des objets de ses sous-classes sans affecter l'intégrité du système. En d'autres termes, le comportement des sous-classes doit être cohérent avec celui des 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");
    }
}

Problème : La classe Duck remplace la méthode fly() pour afficher "Les canards ne peuvent pas voler", nous modifions donc le comportement par défaut défini dans la classe de base Bird, qui est que tous les oiseaux volent ("Flying"). Cela viole LSP car tout code qui s'attend à ce qu'un objet Bird ou ses sous-classes vole ne fonctionnera pas correctement avec un Duck, dont nous savons déjà qu'il ne vole pas.

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

Avec cette approche, Eagle et Duck peuvent être interchangeables là où un Bird est attendu, sans briser les attentes fixées par l'interface Bird. L'exception levée par Duck indique explicitement que les canards ne volent pas, sans modifier le comportement de la superclasse d'une manière qui pourrait provoquer des problèmes inattendus dans le code.

4. Principe de ségrégation des interfaces

Le principe de ségrégation des interfaces (ISP) suggère que les interfaces d'une classe doivent être spécifiques aux clients qui les utilisent. Cela évite les interfaces "grosses" qui nécessitent des implémentations de méthodes non utilisées par les 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
    }
}

Dans l'exemple, nous divisons l'interface Worker en interfaces plus petites (Work, Eat, Sleep) pour garantir que les classes qui les implémentent disposent uniquement des méthodes qui leur sont nécessaires. Cela évite aux classes d'avoir à implémenter des méthodes qui ne leur sont pas pertinentes, améliorant ainsi la clarté et la cohésion du code.

5. Principe d'inversion de dépendance

Le principe d'inversion de dépendance (DIP) suggère que les modules de haut niveau (tels que les classes métier ou d'application, qui implémentent les principales règles métier) ne doivent pas dépendre de modules de bas niveau (classes d'infrastructure, telles que l'accès aux données externes et services qui prennent en charge les opérations de haut niveau). Les deux doivent dépendre d’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();
    }
}

La classe Project dépend désormais d'une abstraction (Developer) au lieu d'une implémentation concrète (BackendDeveloper). Cela permet à différents types de développeurs (par exemple FrontendDeveloper, MobileDeveloper) d'être facilement injectés dans la classe Project sans modifier son code.

Conclusion

L'adoption des principes SOLID améliore non seulement la qualité de votre code, mais renforce également vos compétences techniques, augmente l'efficacité de votre travail et stimule votre cheminement de carrière en tant que développeur de logiciels.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!