DEV Community: Tanguy Bernard

Empiler plusieurs maisons fait-il un immeuble ? Le pattern Composite à la rescousse !

Tanguy Bernard — Thu, 18 Sep 2025 06:58:23 +0000

Introduction

Qui a dit que la modélisation de nos systèmes était de tout repos ?

Dans cet article, nous allons explorer un cas concret inspiré du domaine de l’énergie :
la modélisation des sites équipés de compteurs électriques.

Nous allons ici détailler le chemin de pensée de notre équipe lors du développement d'une nouvelle fonctionnalité.

D'un modèle très simple, en passant par l'héritage et la composition nous terminerons notre voyage sur le Pattern Composite.

1. Définir le besoin métier

Dans notre système, nous avons des sites (des maisons, des écoles, des mairies...). Et nous aimerions connaître la consommation d'énergie de ces sites pour une période donnée et les comparer aux sites de même type. Par exemple pour le calcul de la consommation moyenne par foyer pour une étude INSEE.

Pour faire simple, nous avons un site qui est une entité consommatrice d’électricité qui possède ces attributs :

un nom
un numéro de compteur (identifiant unique)
un type (maison, école, entrepôt…)
une consommation d'énergie (sur une période donnée)

Voici donc un premier modèle :

Cette modélisation suffit tant que nous gérons des sites individuels, mais le métier en a décidé autrement.

2. Nouveau besoin métier : regroupement de sites

En tant que gestionnaire énergétique de la ville de Rennes,
Je veux accéder à la consommation des différents quartiers,
Afin de comparer les zones et orienter les travaux urbains.

En lisant ce besoin, une idée rapide nous vient :

“Remplaçons le numéro de compteur unique par une liste de compteurs afin de les regrouper !”

Mais ce modèle atteint rapidement ses limites :

Tous les compteurs d’un site seraient forcés de partager les mêmes caractéristiques (Le nom d'une maison, n'est pas le même que celui du quatier)
On ne distingue plus un site individuel d’un regroupement de sites.

Le vocabulaire du métier évolue aussi (ubiquitous language) : on parle désormais d'un lot (un groupement de sites), qui est une entité distincte qu’on ne représente pas du tout ici.

On manque également d'exemples pour bien comprendre l'intention métier. Prenons celui-ci déjà structuré :

Scénario: Calcul de la consommation totale du quartier
  Étant donné les sites suivants dans le quartier "Beaulieu" :
      | Nom                       | Consommation (kWh) |
      | Bibliothèque Universitaire| 6000               |
      | Restaurant Universitaire  | 15000               |
  Quand je demande la consommation du quartier "Beaulieu"
  Alors la consommation totale est 21000 kWh

3. Tentative avec l’héritage

À ce moment-là, on se dit :

“Finalement, une maison ou un quartier, c’est un peu la même chose, non ?
Les deux consomment de l’électricité, les deux ont un nom. Que ce soit une maison qui possède une adresse ou encore le nom d'un quartier.
On pourrait peut-être modéliser ça de la même manière !”

Faisons hériter le Lot du Site.

C'est pratique un Lot peut etre utilisé partout où un site est attendu.

Mais cette modélisation est trompeuse.

Un Lot n’est pas une spécialisation d'un site.
Ce n’est pas un cas particulier de site, mais bien un agrégat de sites.
Une maison ne devient pas un immeuble en héritant d’une autre. Et un immeuble n’est pas une maison améliorée.
Et enfin plus technique, on viole le principe de substitution de Liskov.

En effet la violation se produit lorsque la classe enfant modifie le contrat de comportement implicite du parent.

Par exemple quand vous allez au marché acheter des fruits; pour calculer le prix des clémentines on va les peser. On ne pourra pas naturellement remplacer certaines clémentines de notre balance par des kiwis lors de la pesée car le prix du kiwi lui ne dépend pas du poids mais de la quantité. C'est cette différence de comportement dans la pesée qui casse la substitution de liskov car on suppose que la méthode de calcul est forcément liée au poids.

C'est pareil si le Lot hérite du Site, le comportement attendu d’un site (retourner un numéro de compteur, un type, etc.) ne peut pas s’appliquer à un Lot sans introduire des incohérences ou des contournements.

4. Revenir à la réalité pour guider la modélisation

Plutôt que de forcer la logique technique, regardons ce que dit la réalité :

Peut-on regrouper plusieurs maisons ? Oui, cela s’appelle un quartier.
Et si nous empilons les maisons (et qu'on les appelles appartements à la place 😉) ? Cela devient un immeuble.

Ce qu’on cherche à modéliser, c’est donc une structure composée de consommateurs, où chaque entité (simple ou composée) reste un consommateur d'électricité.

La composition permet déjà d’associer des objets différents (par exemple, un lot qui contient des sites).

Le pattern Composite, lui, pousse cette idée plus loin : il permet de composer des objets du même type abstrait, afin de manipuler de manière uniforme les entités simples et celles qui en regroupent plusieurs.

C’est exactement ce que permet le pattern Composite.

5. Le pattern Composite à la rescousse

Avec ce pattern, on introduit une abstraction Consommateur que peuvent implémenter :

les entités simples comme Site
les entités composites comme Lot

Chaque Lot peut contenir des Site, mais aussi d’autres Lot. Le tout est considéré comme un Consommateur. Ainsi, notre système peut manipuler les entités simples et composées de façon uniforme.

Pour concrétiser le schéma, voici comment cela se traduit en Java.

Le Consommateur (le composant) :

public interface Consommateur {
    int getConsommation();
}

Ensuite le Site (la feuille), qui implémente simplement ce contrat :

public class Site implements Consommateur {
    private String nom;
    private String numeroCompteur;
    private String type;
    private int consommation;

    public Site(String nom, String numeroCompteur, String type, int consommation) {
        this.nom = nom;
        this.numeroCompteur = numeroCompteur;
        this.type = type;
        this.consommation = consommation;
    }

    @Override
    public int getConsommation() {
        return this.consommation;
    }
}

Enfin le Lot (le composite):

import java.util.ArrayList;
import java.util.List;

public class Lot implements Consommateur {
    private String nom;
    // La liste contient des interfaces : elle accepte donc des Sites OU des Lots
    private List<Consommateur> enfants = new ArrayList<>();

    public Lot(String nom) {
        this.nom = nom;
    }

    public void ajouter(Consommateur c) {
        enfants.add(c);
    }

    @Override
    public int getConsommation() {
        // On délègue le calcul à chaque enfant, qu'il soit un Site ou un autre Lot
        return enfants.stream()
                      .mapToInt(Consommateur::getConsommation)
                      .sum();
    }
}

Pour reprendre notre exemple, voici son utilisation :

public class Main {
    public static void main(String[] args) {
        // Des sites simples
        Site s1 = new Site("Bibliothèque", "12345678912345", "batiment_publique", 6000);
        Site s2 = new Site("Restaurant U", "012435633785", "batiment_publique", 15000);

        // Un lot (Quartier)
        Lot quartierBeaulieu = new Lot("Beaulieu");
        quartierBeaulieu.ajouter(s1);
        quartierBeaulieu.ajouter(s2);

        // Un autre lot qui contient le premier ! (Ville)
        Lot villeRennes = new Lot("Rennes");
        villeRennes.ajouter(quartierBeaulieu); // On ajoute un Lot dans un Lot
        villeRennes.ajouter(new Site("Mairie", "12345678900045", "batiment_publique", 2000));

        // Le client n'a pas besoin de savoir la structure interne
        System.out.println("Conso totale : " + villeRennes.getConsommation()); 
        // Affiche : 23000
    }
}

6. Ce que l’on y gagne

Une modélisation plus proche de la réalité
Une extensibilité naturelle du modèle à travers le Consommateur
Une logique métier plus claire
Un code plus simple et plus propre

7. Conclusion

Finalement, notre cheminement de pensée est passé par pas mal d'état, nous avions besoin de comprendre le métier, d'y comprendre le sens, d'avoir aussi des exemples sur lesquels nous appuyer. #BDD

Nous savons qu'une modélisation du système n'est jamais figée dans le temps, elle évolue. Dans notre cas, ni l'héritage ni la simple composition pouvaient répondre au problème. Le pattern Composite était le choix le plus cohérent. Il nous a permis de représenter des structures hiérarchiques dans lesquelles les objets simples et composés pouvaient être traités de manière homogène.

Functional Programming and Side Effect Management with Effect-ts

Tanguy Bernard — Fri, 07 Mar 2025 07:37:29 +0000

Side-effect management and code composition are major challenges in programming, particularly in the development of complex applications. Effect-ts is a library that provides elegant solutions to these problems, based on the principles of functional programming.

Let's take a look at how Effect-ts can improve our code, using the example of a post retrieval function.

The initial problem

Let's first consider a classic, trivial implementation of a getPostById function without Effect-ts:

async function getPostById(id) {
    try {
        const response = await fetch(`https://jsonplaceholder.typicode.com/posts/${id}`);
        if (response.status === 404) {
            throw new PostNotFoundError(“”);
        }
        if (!response.ok) {
            throw new HttpError(`HTTP error: ${response.status}`);
        }
        try {
            return await response.json();
        }
        catch (e) {
            throw new JsonParseError(“JSON parsing error”)
        }
    } catch (error) {
        if (error instanceof PostNotFoundError) {
            console.log(`Post missing. Falling back to a default.`)
            return { title: “Sorry, post does not exist !” };
        }
       else if (error instanceof HttpError) {
            console.error(“Exiting.”);
        }
        throw error;
    }
}

This approach has several drawbacks:

Error handling is verbose and difficult to follow.
Side effects (network calls, JSON parsing) are mixed in with business logic.
Error typing is not explicit in the function signature.

The solution with Effect-ts

Here's how we can rewrite this function using Effect-ts:

const fetchWithEffect = (id: number): Effect.Effect<Response, HttpError, never> =>
    pipe(
        Effect.promise(() => fetch(`https://jsonplaceholder.typicode.com/posts/${id}`)),
        Effect.mapError((error) => new HttpError(error.message))
    )

const manageResponse = (res: Response): Effect.Effect<Post, HttpError | PostNotFoundError | JsonParseError, never> =>
    res.status === 404
        ? Effect.fail(new PostNotFoundError(""))
        : res.ok
            ? pipe(
                Effect.promise(() => res.json()),
                Effect.mapError(() => new JsonParseError("JSON parsing error"))
            )
            : Effect.fail(new HttpError(`Erreur HTTP: ${res.status}`));


const getPostIdWithEffect = (id: number): Effect.Effect<string, Error, never> =>
    pipe(
        fetchWithEffect(id),
        Effect.flatMap(manageResponse),
        Effect.catchTags({
            HttpError: (error) =>
                Effect.logError(`Exiting.`).pipe(
                    Effect.flatMap(() => Effect.fail(error))
                ),
            PostNotFoundError: () =>
                Effect.log(`Post missing. Falling back to a default.`).pipe(
                    Effect.map(() => ({title: "Sorry, post does not exist !"}))
                ),
        }),
        Effect.flatMap((post: Post) => Effect.succeed(post.title)),
        Effect.orElseFail(() => new Error("Request failed and no fallback available !"))
    );

Advantages of the Effect-ts approach

Safe error typing: Error types are explicitly declared in the effect signature, making the function's contract clearer.
Better handling of side effects: Side effects are encapsulated in Effect structures, allowing a clear separation between effect description (what needs to be done) from its actual execution.
Easier composition: The use of pipe and operators such as flatMap enable effects to be composed in a readable and maintainable way.
Declarative error handling: The use of catchTags allows errors to be handled in a more declarative and typed way.
Separation of concerns: The logic of data retrieval, error handling and transformation is separated into different functions.

Conclusion

By adopting Effect-ts and the principles of functional programming, we obtain more robust code that's easier to test and maintain.
Explicit side-effect management and functional composition allow us to reason more easily about our code, while benefiting from a powerful type system that catches potential errors right at compile-time.
This approach, although initially more verbose, offers better scalability and maintainability for complex projects, by providing stronger guarantees on the behavior of our code.

Further Exploration

Effect-ts is much more than just a functional library for managing side effects. It's actually a complete ecosystem offering a multitude of tools for the development of modern, robust TypeScript applications.

In addition to effects management and code composition, Effect-ts offers data structures such as Either and Option, as well as tools for data validation, database access and API development. These abstractions enable the creation of more robust and maintainable applications, a topic we may explore further in a future article.

Thanks

Thank you Paul Couthouis for introducing me to this library.

https://effect.website/