Programmation Réactive vs Programmation Pragmatique

Programmation Réactive vs Programmation Pragmatique : Le Combat du Siècle !

Il était une fois , un monde où chacun pense détenir la vérité absolue. Aujourd’hui, nous allons opposer deux approches bien connues : la programmation réactive, qui veut transformer ton code en un orchestre synchronisé de flux de données, et la programmation pragmatique, qui préfère le bon vieux "ça marche, c'est l'essentiel".

Installe-toi confortablement et voyons comment ces deux écoles se débrouillent face à quelques situations bien réelles.

Round 1 : Récupération de données

🦸 Programmation Réactive : "Tout est un Flux"

Imagine un super-héros du code qui refuse d’attendre bêtement une réponse d’une API. Il veut que chaque événement soit traité au moment opportun, sans bloquer son programme. Voici comment un réactif pense :

Mono<String> data = WebClient.create("https://api.example.com")
    .get()
    .retrieve()
    .bodyToMono(String.class);

data.subscribe(response -> System.out.println("Réponse reçue : " + response));

🚀 Ici, on ne bloque pas ! On dit à notre programme : "Quand t’as la réponse, dis-moi."

🛠️ Programmation Pragmatique : "Une ligne, un résultat, pas de chichi"

Le pragmatique, lui, veut que ça marche, vite et bien. Pas question de s’embêter avec des abonnements et des flux.

RestTemplate restTemplate = new RestTemplate();
String response = restTemplate.getForObject("https://api.example.com", String.class);
System.out.println("Réponse reçue : " + response);

💡 C’est simple, lisible et direct ! Bon, par contre, si l’API met du temps à répondre… ton programme prend un café en attendant.

Round 2 : Gestion des erreurs

😎 Programmation Réactive : "Les erreurs sont des événements comme les autres"

 Mono<String> data = WebClient.create("https://api.example.com")
    .get()
    .retrieve()
    .bodyToMono(String.class)
    .onErrorResume(error -> Mono.just("Erreur gérée : " + error.getMessage()));

data.subscribe(System.out::println);

🎩 Avantages : Pas de crash, l’erreur est traitée comme une simple variation du flux.

💢 Programmation Pragmatique : "Try-Catch et basta"

try {
    String response = restTemplate.getForObject("https://api.example.com", String.class);
    System.out.println("Réponse reçue : " + response);
} catch (Exception e) {
    System.out.println("Oups, une erreur : " + e.getMessage());
}

🔨 C’est du solide. Si ça plante, on affiche un message d’erreur et on continue notre vie.

Round 3 : Concurrence et performance

⚡ Programmation Réactive : "Chaque thread compte"

Le réactif est un stratège. Il sait que les threads sont précieux et qu'il faut les utiliser intelligemment :

Flux.range(1, 5)
    .flatMap(i -> Mono.fromCallable(() -> {
        Thread.sleep(1000); // Simulation d'une tâche longue
        return "Tâche " + i + " terminée";
    }).subscribeOn(Schedulers.boundedElastic()))
    .subscribe(System.out::println);

⏳ Grâce à la magie de la réactivité, tout est exécuté en parallèle sans bloquer un seul thread principal.

🐢 Programmation Pragmatique : "Un thread à la fois, on gère comme on peut"

for (int i = 1; i <= 5; i++) {
    new Thread(() -> {
        try {
            Thread.sleep(1000);
            System.out.println("Tâche " + i + " terminée");
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }).start();
}

💭 Ça marche… mais bonjour la gestion des threads ! On multiplie les threads comme des gremlins et ça peut vite devenir ingérable.

Verdict Final : Qui est le grand vainqueur ?

🥁 Roulement de tambour…

• La programmation réactive est puissante pour les applications massivement concurrentes, mais elle peut vite devenir un cauchemar de complexité (bonjour le debug !).

• La programmation pragmatique est simple et efficace, mais peut vite atteindre ses limites en termes de performance et d’évolutivité.

Moralité : Comme d’habitude en programmation, tout dépend du contexte. Si ton application doit gérer des milliers de requêtes sans broncher, la réactivité est ton amie. Si tu veux un code lisible et rapide à coder, reste pragmatique.

En attendant, bon code, et que les exceptions soient avec toi ! 🚀