Simplifier les systèmes complexes grâce aux abstractions

1. Abstraction à plusieurs niveaux

Quand on commence à programmer, tout semble simple : on écrit une classe, on appelle une méthode, on obtient un résultat. Mais dans les projets réels, tout se complexifie : des dizaines de classes, des centaines de méthodes, des milliers de lignes de code... Et si une équipe travaille sur le projet, la tâche devient encore plus difficile ! Comment ne pas se noyer dans ce chaos ?

La réponse consiste à décomposer le complexe en éléments simples, et mieux encore — en niveaux d’abstraction.

Qu’est-ce que les niveaux d’abstraction ?

Imaginez-les comme des étages dans un grand immeuble : à chaque étage sa propre vie, mais tous les étages sont liés entre eux. En programmation, on distingue généralement les couches (niveaux) suivants :

• Interface utilisateur (UI) — ce que voit l’utilisateur.
• Logique métier — les règles et processus qui réalisent l’essence de l’application.
• Accès aux données (DAO, Repository) — le travail avec la base de données ou les fichiers.

Chaque couche travaille avec des abstractions sans connaître les détails des autres couches. Par exemple, la logique métier n’a pas besoin de savoir comment l’interface utilisateur est implémentée ni comment les données sont stockées — elle a seulement besoin qu’il existe des méthodes comme saveOrder() ou findUserById().

Une analogie de la vie courante

Imaginez un restaurant. Les clients (UI) passent commande via le serveur (abstraction d’interface), le cuisinier (logique métier) prépare le plat, et le magasinier (accès aux données) contrôle la disponibilité des produits en stock. Les clients ne savent pas comment le cuisinier prépare exactement le plat, et le cuisinier ne s’intéresse pas à l’endroit où se trouve la pomme de terre — l’essentiel est qu’elle soit disponible.

2. Exemple : architecture multicouche en pratique

Développons notre projet d’apprentissage — par exemple, une application de suivi des tâches (task manager). Nous savons déjà créer des classes pour les tâches ; complexifions maintenant l’ensemble et séparons l’application en couches.

Identifier les abstractions

• Task — description abstraite d’une tâche : une tâche a un titre, un statut, des méthodes d’exécution.
• TaskRepository — abstraction pour le stockage des tâches (peu importe où — en mémoire, dans un fichier, dans une base de données).
• TaskService — logique métier : ajout de tâches, recherche, exécution.

Classes abstraites et interfaces

// Couche de logique métier
public abstract class Task {
    private String title;
    private boolean completed;

    public Task(String title) {
        this.title = title;
        this.completed = false;
    }

    public abstract void complete();

    public String getTitle() { return title; }
    public boolean isCompleted() { return completed; }

    protected void setCompleted(boolean completed) { this.completed = completed; }
}

// Couche d’accès aux données (abstraction)
public interface TaskRepository {
    void save(Task task);
    Task findByTitle(String title);
    List<Task> findAll();
}

Implémentation des couches

Implémentation de Task

public class WorkTask extends Task {
    private String deadline;

    public WorkTask(String title, String deadline) {
        super(title);
        this.deadline = deadline;
    }

    @Override
    public void complete() {
        setCompleted(true);
        System.out.println("La tâche de travail '" + getTitle() + "' est terminée pour l'échéance " + deadline);
    }
}

Implémentation de TaskRepository

public class InMemoryTaskRepository implements TaskRepository {
    private List<Task> tasks = new ArrayList<>();

    @Override
    public void save(Task task) {
        tasks.add(task);
    }

    @Override
    public Task findByTitle(String title) {
        for (Task task : tasks) {
            if (task.getTitle().equals(title)) {
                return task;
            }
        }
        return null;
    }

    @Override
    public List<Task> findAll() {
        return new ArrayList<>(tasks);
    }
}

Implémentation de TaskService

public class TaskService {
    private TaskRepository repository;

    public TaskService(TaskRepository repository) {
        this.repository = repository;
    }

    public void addTask(Task task) {
        repository.save(task);
    }

    public void completeTask(String title) {
        Task task = repository.findByTitle(title);
        if (task != null) {
            task.complete();
        } else {
            System.out.println("Tâche introuvable : " + title);
        }
    }

    public void showAllTasks() {
        for (Task task : repository.findAll()) {
            System.out.println(task.getTitle() + " — " + (task.isCompleted() ? "terminée" : "non terminée"));
        }
    }
}

Utilisation dans la classe principale

public class Main {
    public static void main(String[] args) {
        TaskRepository repo = new InMemoryTaskRepository();
        TaskService service = new TaskService(repo);

        service.addTask(new WorkTask("Rédiger le rapport", "2025-07-15"));
        service.addTask(new WorkTask("Préparer la présentation", "2025-07-16"));

        service.showAllTasks();

        service.completeTask("Rédiger le rapport");
        service.showAllTasks();
    }
}

Qu’avons‑nous obtenu ?

• La classe principale (Main) ne sait pas comment est organisé le stockage des tâches — elle travaille avec l’abstraction TaskRepository.
• TaskService ne sait pas quels types de tâches existent — il travaille avec la classe abstraite Task.
• Si demain nous voulons stocker les tâches dans une base de données au lieu de la mémoire — il suffit d’implémenter une nouvelle classe DatabaseTaskRepository, sans réécrire la logique métier ni l’UI.
• Si un nouveau type de tâche apparaît, par exemple HomeTask, — on ajoute simplement une nouvelle classe dérivée.

3. Avantages pour le travail en équipe

Dans les grands projets, il est rare qu’une seule personne écrive tout. En général, l’équipe se répartit en « front-end », « back-end », « développeurs de la couche de stockage », etc. Comment les abstractions les aident-elles à ne pas se marcher sur les pieds ?

Répartition des responsabilités

Chacun travaille à son propre niveau d’abstraction.

• Un développeur écrit l’implémentation de TaskRepository pour travailler avec la base.
• Un autre s’occupe de la logique métier (TaskService).
• Un troisième développe l’interface utilisateur.

Le contrat entre les couches est fixé par les abstractions.

Tant que tout le monde s’accorde sur le fait que TaskRepository possède les méthodes save, findByTitle, findAll, les détails d’implémentation importent peu.

Facilité de test et de remplacement des composants

• On peut facilement remplacer une implémentation par une autre (par exemple, utiliser InMemoryTaskRepository pour les tests et, en production, une base de données).
• Le testeur peut remplacer la couche de données par un faux objet (mock) pour tester la logique métier isolément.

Évolution indépendante

• Si quelqu’un décide d’ajouter un nouveau type de tâche, il ne casse pas le code existant — il implémente simplement une nouvelle sous-classe de Task.
• Si un nouveau mode de stockage apparaît, seule l’implémentation de l’interface change, le reste du code ne bouge pas.

4. Bonnes pratiques : comment ne pas abuser des abstractions

L’abstraction est comme le sel dans un plat : sans elle c’est fade, mais si on en met trop — on gâche tout. Voici quelques conseils :

Utilisez des abstractions là où elles simplifient réellement le système.
Inutile de créer une classe abstraite pour le principe. S’il n’existe qu’un seul type de tâche, l’abstraction n’est peut-être pas nécessaire.

Documentez les classes et méthodes abstraites.
Une bonne documentation aide à comprendre ce que l’héritier doit implémenter et pourquoi.

Veillez à ce que les abstractions aient du sens.
Une classe abstraite doit exprimer un comportement et/ou un état réellement commun.

Ne mélangez pas les responsabilités.
N’ajoutez pas à une classe abstraite des méthodes qui ne sont utiles qu’à un seul des descendants.

5. Abstraction dans les grands systèmes : exemple concret

Voyons comment l’abstraction fonctionne dans un projet vraiment important — par exemple, une boutique en ligne.

Couches du système

• Contrôleurs (UI) : reçoivent les requêtes de l’utilisateur (par exemple, « passer commande »).
• Services (logique métier) : vérifient la disponibilité des produits, calculent les remises, créent la commande.
• Référentiels (accès aux données) : enregistrent les commandes, produits, utilisateurs dans la base de données.

Exemple d’abstractions

// Abstraction pour le service de traitement des commandes
public interface OrderService {
    void createOrder(Order order);
    Order findOrderById(String id);
}

// Abstraction pour le référentiel des commandes
public interface OrderRepository {
    void save(Order order);
    Order findById(String id);
}

Chaque couche ne connaît que sa propre abstraction. Si demain on décide de stocker les commandes dans le cloud — seule l’implémentation de OrderRepository change.

Interaction des couches — schéma

[UI/Controller] <--> [OrderService (abstraction)] <--> [OrderRepository (abstraction)] <--> [Base de données]

• Chaque couche travaille avec une abstraction, sans connaître les détails de la couche inférieure.
• Cela permet de développer, tester et faire évoluer chaque couche indépendamment.

Abstraction et maintenance du code

• Ajout de nouvelles fonctionnalités facile (nouveaux types de tâches, paiements, modes de transport).
• Correction des bugs facilitée (on corrige un bug à un endroit — tous les descendants obtiennent la mise à jour).
• Tests facilités (on peut remplacer des couches par des « mocks » pour les tests unitaires).

6. Erreurs typiques lors de la conception d’abstractions

Erreur n° 1 : Abstraction excessive. Parfois on veut créer une classe abstraite pour chaque broutille. Mais s’il n’existe qu’un seul type d’entité, ne le faites pas par effet de mode — cela ne fera que compliquer le code.

Erreur n° 2 : Abstraction trop floue. Si votre classe abstraite décrit trop de choses et n’a pas de domaine de responsabilité clair, ses descendants seront forcés d’implémenter des méthodes inutiles ou de conserver des champs « morts ».

Erreur n° 3 : Violation du principe de responsabilité unique. Une classe abstraite ne doit couvrir qu’un seul domaine de comportement. Évitez de mélanger, par exemple, des méthodes de stockage et des méthodes de logique métier dans une même classe abstraite.

Erreur n° 4 : Couplage rigide entre les couches. Si la couche de logique métier dépend directement d’une implémentation concrète du stockage (par exemple, utilise new InMemoryTaskRepository() en son sein), alors lors du remplacement du stockage il faudra réécrire tout le code. Utilisez des abstractions (interfaces, classes abstraites) pour réduire le couplage.

Erreur n° 5 : Documentation insuffisante. L’abstraction est un contrat, et il doit être clairement décrit. Si vous n’expliquez pas ce que doit faire l’héritier, vous risquez d’obtenir des erreurs inattendues ou un « excès de créativité » des collègues.