(D) : Application du « Principe d'inversion de dépendance » avec Typescript et Java

Concepts

SOLID est un acronyme qui représente cinq principes fondamentaux de la programmation orientée objet, proposés par Robert C. Martin - Oncle Bob. Ici vous pouvez en savoir plus sur son article.
Ces principes visent à améliorer la structure et la maintenance du code, le rendant plus flexible, évolutif et plus facile à comprendre. De tels principes aident le programmeur à créer des codes plus organisés, en répartissant les responsabilités, en réduisant les dépendances, en simplifiant le processus de refactorisation et en favorisant la réutilisation du code.

Le « D » dans l'acronyme signifie « Principe d'inversion de dépendance ». La phrase utilisée par Oncle Bob pour définir ce principe était :

"Les modules de haut niveau ne devraient pas dépendre de modules de bas niveau. Les deux devraient dépendre d'abstractions. Les abstractions ne devraient pas dépendre de détails. Les détails devraient dépendre d'abstractions"

Le Principe d'inversion des dépendances vise à réduire le couplage entre les composants d'un système, favorisant ainsi une plus grande flexibilité, maintenabilité et testabilité.

Problèmes résolus par DIP

• Couplage étroit : Lorsqu'un module dépend directement d'une implémentation concrète, les modifications apportées à cette implémentation peuvent affecter d'autres modules.
• Difficulté de tester : tester des unités de code directement couplées à des implémentations spécifiques est plus compliqué, car cela nécessite l'utilisation de ces implémentations concrètes, ce qui rend difficile la création de simulations ou de stubs.
• Faible réutilisabilité : Un module fortement couplé à des détails concrets est moins réutilisable dans d'autres contextes.

Application pratique

Nous allons créer un code chargé d'envoyer des notifications par email, afin d'analyser les problèmes et les solutions possibles pour les résoudre

Java

class EmailService {
    public void sendEmail(String message) {
        System.out.println("Sending email: " + message);
    }
}

class Notification {
    private EmailService emailService;

    public Notification() {
        this.emailService = new EmailService();
    }

    public void notify(String message) {
        this.emailService.sendEmail(message);
    }
}

// Uso
public class Main {
    public static void main(String[] args) {
        Notification notification = new Notification();
        notification.notify("Welcome to our service!");
    }
}

Manuscrit

class EmailService {
    sendEmail(message: string): void {
        console.log(`Sending email: ${message}`);
    }
}

class Notification {
    private emailService: EmailService;

    constructor() {
        this.emailService = new EmailService();
    }

    notify(message: string): void {
        this.emailService.sendEmail(message);
    }
}

// Uso
const notification = new Notification();
notification.notify("Welcome to our service!");

Problèmes :

• La classe Notification dépend directement d'une implémentation concrète (EmailService).
• Si nous voulons changer le canal de notification (ex. : SMS), nous devons changer le code de notification.

Solutions et avantages :

• La notification n'a pas besoin de connaître les détails sur la façon dont le message est envoyé.
• Facilité de remplacement ou d'ajout de nouveaux canaux de communication.
• Nous pouvons tester Notification de manière isolée, sans nous appuyer sur des implémentations réelles.

Java

public interface MessageService {
    void sendMessage(String message);
}

public class EmailService implements MessageService {
    @Override
    public void sendMessage(String message) {
        System.out.println("Sending email: " + message);
    }
}

public class SMSService implements MessageService {
    @Override
    public void sendMessage(String message) {
        System.out.println("Sending SMS: " + message);
    }
}

public class Notification {
    private final MessageService messageService;

    public Notification(MessageService messageService) {
        this.messageService = messageService;
    }

    public void notify(String message) {
        messageService.sendMessage(message);
    }
}

// Uso
public class Main {
    public static void main(String[] args) {
        Notification emailNotification = new Notification(new EmailService());
        emailNotification.notify("Welcome via Email!");

        Notification smsNotification = new Notification(new SMSService());
        smsNotification.notify("Welcome via SMS!");
    }
}

Manuscrit

interface MessageService {
    sendMessage(message: string): void;
}

class EmailService implements MessageService {
    sendMessage(message: string): void {
        console.log(`Sending email: ${message}`);
    }
}

class SMSService implements MessageService {
    sendMessage(message: string): void {
        console.log(`Sending SMS: ${message}`);
    }
}

class Notification {
    private messageService: MessageService;

    constructor(messageService: MessageService) {
        this.messageService = messageService;
    }

    notify(message: string): void {
        this.messageService.sendMessage(message);
    }
}

// Uso
const emailNotification = new Notification(new EmailService());
emailNotification.notify("Welcome via Email!");

const smsNotification = new Notification(new SMSService());
smsNotification.notify("Welcome via SMS!");

3. Tests unitaires

Java

public class MockMessageService implements MessageService {
    @Override
    public void sendMessage(String message) {
        System.out.println("Mock message sent: " + message);
    }
}

// Teste com o mock
public class Main {
    public static void main(String[] args) {
        MessageService mockMessageService = new MockMessageService();
        Notification mockNotification = new Notification(mockMessageService);
        mockNotification.notify("Test message");
    }
}

Manuscrit

class MockMessageService implements MessageService {
    sendMessage(message: string): void {
        console.log(`Mock message sent: ${message}`);
    }
}

// Teste com o mock
const mockNotification = new Notification(new MockMessageService());
mockNotification.notify("Test message");

Conclusion

Le principe d'inversion de dépendance (DIP) est un pilier fondamental pour des projets flexibles et robustes. Il permet de réduire le couplage entre les classes, de faciliter la réutilisation du code et d'améliorer la testabilité des applications. En s'appuyant sur des abstractions, votre système devient plus adaptable au changement et extensible avec de nouvelles fonctionnalités. L'exemple pratique a démontré comment de petits ajustements de conception peuvent résoudre des problèmes de maintenance récurrents. L'application de DIP en conjonction avec d'autres principes SOLID garantit un code plus propre et prêt à croître. L'adoption de ces concepts est essentielle pour les développeurs recherchant l'excellence en architecture logicielle.

Références bibliographiques

• Martin, Robert C. Développement de logiciels agiles, principes, modèles et pratiques. Prentice Hall, 2002.
• Thiago Leite et Carvalho. Orientation de l'objet. Maison du Code, 2014.

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!