♟2026.05.22
Spirales et chevaliers | 5. finitions et visualisations

Nous sommes arrivés, fonctionnellement, au bout de l’exercice en produisant cette figure-ci lors de l’épisode précédent:

Restent quelques finitions, à commencer par le fait de pouvoir utiliser un fichier JSON pour décrire la figure attendue. Ensuite, on pourra essayer de générer des images sympa!

Configuration

On cherche à décrire la configuration dans un fichier avec cette structure:

{
    "n_layers": 20,
    "players": [
        {"color": "r", "offsets": [[1, 2], [-1, 2], [2, 1], [-2, 1], [1, -2], [-1, -2], [2, -1], [-2, -1]]},
        {"color": "k", "offsets": [[1, 2], [-1, 2], [2, 1], [-2, 1], [1, -2], [-1, -2], [2, -1], [-2, -1]]}
    ]
}

Créons une dataclass pour la configuration:

# spiral.py
@dataclass
class Config:
    n_layers: int
    players: list[Player]

    @classmethod
    def from_json(cls, path: pathlib.Path):
        with path.open("r", encoding="utf-8") as fp:
            data = json.load(fp)
        if not ("n_layers" in data and "players" in data):
            raise ValueError("Config: missing n_layers or players")        
        players = [Player.from_dict(p) for p in data['players']]
        return cls(int(data['n_layers']), players)

En modifiant Player pour pouvoir aussi être créé à partir d’un dictionnaire:

# player.py

@dataclass
class Player:
    # ...
    @classmethod
    def from_dict(cls, data: dict):
        if not ("color" in data and "offsets" in data):
            raise ValueError("Player: missing color or offsets")
        
        return cls(str(data["color"]), [(int(offset[0]), int(offset[1])) for offset in data['offsets']])

Le main, enfin, va lire le fichier JSON passé en paramètre de l’appel au programme, ou fourni par l’utilisateur via un input:

# spiral.py
if __name__ == "__main__":
    if len(sys.argv) >= 2:
        path = pathlib.Path(sys.argv[1])
    else:
        path = pathlib.Path(input("Path to config file: "))

    config = Config.from_json(path)
    
    board = Board(config.n_layers, config.players)
    show_board(board, save_as=pathlib.Path(str(path).replace('.json', '.png')))

Si on lance python spiral.py two_knights.json (avec bien sûr la configuration ci-dessus dans two_knights.json!), on obtient bien notre figure:

Parfait. Voyons ce qu’on peut faire de plus.

Visualisations

Prenons notre configuration à quatre cavaliers, et remplaçons deux des cavaliers par des “super-cavaliers”, capable d’aller deux fois plus loin. Donc, au lieu de (1, 2), ils ont un offset de (2, 4), etc:

Un cavalier, un super-cavalier, et un super-super-cavalier, avec un offset (3, 6):

Un cavalier, un super-cavalier, et un “vizir” (offsets en “croix” (1, 0), (0, 1), (-1, 0), (0, -1)):

Jusqu’à présent, nous n’avons fait que des pièces “symétriques”, mais rien ne nous empêche de définir des pattern plus arbitraires pour les déplacements des pièces. Prenons la configuration suivante:

{
    "n_layers": 500,
    "players": [
        {"color": "r", "offsets": [[-1, -1], [-1, 1], [1, 2], [2, 1], [1, -2], [2, -1]]},
        {"color": "k", "offsets": [[1, -1], [1, 1], [-1, 2], [-2, 1], [-1, -2], [-2, -1]]},
        {"color": "y", "offsets": [[1, 0], [-1, 0], [0, 2], [0, -3]]}
    ]
}

On a une pièce qui va plus loin à droite que à gauche, une autre qui va plus loin à gauche que à droite, et une dernière qui avance plus loin en vertical qu’en horizontal. Le résultat:

Je pense qu’on peut dire que l’expérience est réussie !

Aller, un dernier pour la route, faisons se batailler les sept cavaliers de l’arc-en-ciel sur une spirale à 1000 couches:

{
    "n_layers": 1000,
    "players": [
        {"color": "red", "offsets": [[1, 2], [-1, 2], [2, 1], [-2, 1], [1, -2], [-1, -2], [2, -1], [-2, -1]]},
        {"color": "orange", "offsets": [[1, 2], [-1, 2], [2, 1], [-2, 1], [1, -2], [-1, -2], [2, -1], [-2, -1]]},
        {"color": "yellow", "offsets": [[1, 2], [-1, 2], [2, 1], [-2, 1], [1, -2], [-1, -2], [2, -1], [-2, -1]]},
        {"color": "green", "offsets": [[1, 2], [-1, 2], [2, 1], [-2, 1], [1, -2], [-1, -2], [2, -1], [-2, -1]]},
        {"color": "cyan", "offsets": [[1, 2], [-1, 2], [2, 1], [-2, 1], [1, -2], [-1, -2], [2, -1], [-2, -1]]},
        {"color": "blue", "offsets": [[1, 2], [-1, 2], [2, 1], [-2, 1], [1, -2], [-1, -2], [2, -1], [-2, -1]]},
        {"color": "violet", "offsets": [[1, 2], [-1, 2], [2, 1], [-2, 1], [1, -2], [-1, -2], [2, -1], [-2, -1]]}
    ]
}

Bon, ça met quelques minutes à tourner et je ne pense pas qu’on me demandera de designer le drapeau de la prochaine Pride… mais ça marche.

[lien permanent]

♟2026.05.19
Spirales et chevaliers | 4. plus joli, plus pratique

Le code est maintenant disponible sur https://codeberg.org/adfoucart/spirals.

Nous sommes maintenant capable de calculer le pattern pour (au moins) deux “joueurs” avec cavalier:

Mais le code commence à devenir un peu brouillon. Refactorisons.

Module vue

Première chose: prenons les codes de visualisation et donnons leur leur propre module, view.py:

# view.py
from typing import Iterable
from matplotlib import pyplot as plt

from player import Player

def show_points_with_lines(positions: Iterable[tuple[int, int]]) -> None:
    plt.figure()
    i = 0
    for (x1, y1), (x2, y2) in itertools.pairwise(positions):
        if i >= 10:
            break
        plt.plot(x1, y1, 'bo')
        plt.plot([x1, x2], [y1, y2], 'k-')
        i += 1
    plt.show()

def show_points(positions: Iterable[tuple[int, int, Player]]) -> None:
    plt.figure()
    for x, y, player in positions:
        plt.plot(x, y, f'{player.color}+')
    plt.axis('equal')
    plt.show()

Cela nous permet d’alléger spiral.py, qui a terme devrait uniquement se préoccuper de récupérer la configuration à afficher, et d’appeler des fonctions des différents modules.

Visualisation du plateau

Je n’aime pas trop le fait d’envoyer ce générateur à show_point. Ni d’ailleurs d’afficher l’image avec des plt.plot. Outre le fait que ce n’est pas très joli, cela prend beaucoup de temps à générer si on augmente le nombre de points. Je préfèrerais pouvoir visualiser le plateau comme une image, où chaque position correspond à un pixel, et contrôler le nombre de “couches” de la spirale à afficher. Une fonction comme:

# view.py
def show_board(board: Board, layers: int) -> None:
    ...

Pour créer l’image, on peut alors parcourir tous les pixels à générer et récupérer le joueur qui se trouve (ou non) à cette position. On doit d’abord modifier board.py pour implémenter __getitem__, et ainsi pouvoir obtenir le joueur d’une position via board[pos]:

# board.py
class Board:
    # ...
    def __getitem__(self, position: tuple[int, int]) -> Player:
        return self.values[position]

Et la vue:

# view.py
def show_board(board: Board, layers: int) -> None:
    image = []
    for y in range(-layers, layers+1):
        row = []
        for x in range(-layers, layers+1):
            player = board[(x, y)]
            row.append(player)
        image.append(row)
    plt.figure()
    plt.imshow(image)
    plt.show()

Le problème, maintenant, est que matplotlib ne sait pas traduire des Player en couleur. Je ne peux pas non plus juste utiliser player.color: il me faut des valeurs numériques pour les pixels. Modifions un peu Player pour qu’à chaque joueur soit attribué un identifiant unique, qu’on va générer automatiquement à chaque fois qu’on instancie un nouveau joueur.

# player.py
from typing import Iterable
from dataclasses import dataclass, field

_current_id = 0
def nextid():
    global _current_id
    _current_id += 1
    return _current_id

@dataclass
class Player:
    color: str
    offsets: Iterable[tuple[int, int]]
    _id: int = field(default_factory=nextid)

    @property
    def id(self):
        return self._id

On peut maintenant utiliser cet id dans show_board, en traitant au passage le cas None pour mettre la valeur 0:

# view.py
def show_board(board: Board, layers: int) -> None:
    image = []
    for y in range(-layers, layers+1):
        row = []
        for x in range(-layers, layers+1):
            player = board[(x, y)]
            if player is None:
                row.append(0)
            else:
                row.append(player.id)
        image.append(row)
    plt.figure()
    plt.imshow(image)
    plt.show()

Génération par couche

On génère pour l’instant toujours un “nombre de points”. Pour s’accorder avec show_board, ce serait beaucoup plus pratique de donner un nombre de couche. Et vu la façon dont le code est en train de s’organiser, je pense que ça devrait être la responsabilité de board de se remplir. Mettons le générateur de points de la spirale dans un fichier séparé, pour mieux organiser les choses:

# generators.py
from typing import Generator
import itertools

LEFT = (-1, 0)
RIGHT = (1, 0)
UP = (0, 1)
DOWN = (0, -1)
SPIRAL_CYCLE = [(RIGHT, 1), (UP, 0), (LEFT, 1), (DOWN, 0)]

def position_generator() -> Generator[tuple[int, int], None, None]:
    x, y = 0, 0
    dx, dy = 0, 0
    length = 0
    current_pos_in_segment = 0
    cycle = itertools.cycle(SPIRAL_CYCLE)
    
    while True:
        yield x, y 
        if current_pos_in_segment == length:
            direction, dl = next(cycle)
            dx, dy = direction
            length += dl
            current_pos_in_segment = 0
        x += dx
        y += dy
        current_pos_in_segment += 1

Et transférons _next_valid_point_for_player dans board, pour pouvoir également ajouter une méthode fill. On veut s’arrêter dès que tous les générateurs des différents joueurs ont dépassé la couche maximale que je voudrai afficher. On va donc retenir la “couche actuelle” de chaque joueur dans un dictionnaire, et la mettre à jour à chaque fois qu’on place un point:

# board.py
class Board:
    # ...
    def _next_valid_point_for_player(self,
                                        points: Iterable[tuple[int, int]],
                                        players: Iterable[Player]) -> tuple[int, int]:
        for x, y in points:
            if not self.is_available((x, y)): 
                continue
            if any(self.is_visible_from((x, y), player) for player in players):
                continue
            return x, y
        
    def fill(self, max_layers: int, players: Iterable[Player]) -> None:
        n_points = 0
        generators = [(player, position_generator()) for player in players]
        layer_per_player = {}
        for player in players:
            layer_per_player[player.id] = 0
        while any(layer <= max_layers for layer in layer_per_player.values()):
            for player, generator in generators:
                if len(players) == 1:
                    x, y = self._next_valid_point_for_player(generator, player)
                else:
                    x, y = self._next_valid_point_for_player(generator, [p for p in players if p != player])
                self.put((x, y), player)
                n_points += 1
                layer_per_player[player.id] = max(abs(x), abs(y))

Ceci nous permet de considérablement simplifier spiral.py:

from board import Board
from player import Player
from view import show_points, show_board

if __name__ == "__main__":
    board = Board()
    players = [
        Player(color='r', offsets=[(1, 2), (-1, 2), (2, 1), (-2, 1), (1, -2), (-1, -2), (2, -1), (-2, -1)]),
        Player(color='k', offsets=[(1, 2), (-1, 2), (2, 1), (-2, 1), (1, -2), (-1, -2), (2, -1), (-2, -1)])
    ]
    board.fill(20, players)
    show_board(board, 20)

Voyons ce que ça donne:

Point positif: on a bien des pixels au lieu des croix, le rendu est globalement meilleur. Point négatif: on a perdu les couleurs qu’on avait définies dans Player: plt.imshow utilise une colormap pour choisir les couleurs en fonction de la valeur, et pour l’instant on est dans la colormap par défaut, viridis.

Les bonnes couleurs

Redéfinir une colormap n’est heureusement pas compliqué. Petite modification de view.py:

# view.py
from matplotlib.colors import ListedColormap 

def show_board(board: Board, max_layers: int):
    # ...
    cmap = ListedColormap(['w'] + [p.color for p in board.players]) 
    # ...
    plt.imshow(image, cmap=cmap) 
    plt.show()

Il faut cependant pour ça que Board connaisse la liste des players, ce qui n’est pas encore le cas. Au passage, on peut aussi lui faire retenir max_layers, ce qui va nous permettre de simplifier plusieurs choses. En fait, on peut même initialiser tout ça dans le constructeur, et laisser le constructeur appeler fill:

# board.py
class Board:
    def __init__(self, max_layers: int, players: Iterable[Player]):
        self.values: dict[tuple[int, int], Player | None] = defaultdict(lambda: None)
        self.players = players
        self.max_layers = max_layers
        self._fill()
    # ...
    def _fill(self) -> None:
        n_points = 0
        generators = [(player, position_generator()) for player in self.players]
        layer_per_player = {}
        for player in self.players:
            layer_per_player[player.id] = 0
        while any(layer <= self.max_layers for layer in layer_per_player.values()):
            for player, generator in generators:
                if len(self.players) == 1:
                    x, y = self._next_valid_point_for_player(generator, player)
                else:
                    x, y = self._next_valid_point_for_player(generator, [p for p in self.players if p != player])
                self.put((x, y), player)
                n_points += 1
                layer_per_player[player.id] = max(abs(x), abs(y))

Le main devient alors:

# spiral.py
if __name__ == "__main__":
    players = [
        Player(color='r', offsets=[(1, 2), (-1, 2), (2, 1), (-2, 1), (1, -2), (-1, -2), (2, -1), (-2, -1)]),
        Player(color='k', offsets=[(1, 2), (-1, 2), (2, 1), (-2, 1), (1, -2), (-1, -2), (2, -1), (-2, -1)])
    ]
    board = Board(20, players)
    show_board(board)

Et show_board peut également utiliser le max_layers fourni par board:

# view.py
def show_board(board: Board) -> None:
    image = []
    for y in range(-board.max_layers, board.max_layers+1):
        row = []
        for x in range(-board.max_layers, board.max_layers+1):
            player = board[(x, y)]
            if player is None:
                row.append(0)
            else:
                row.append(player.id)
        image.append(row)
    cmap = ListedColormap(['w'] + [p.color for p in board.players])
    plt.figure()
    plt.imshow(image, cmap=cmap)
    plt.show()

Ce qui nous donne:

On peut maintenant tester des configurations différentes. Par exemple: quatre joueurs, et afficher les 500 premières couches:

Ca prend quelques secondes à calculer, mais là on arrive dans quelque chose d’intéressant!

Image

Dernière petite modification avant de marquer une pause: plutôt que d’afficher un plot, on peut sauvegarder directement l’image du plateau dans un fichier png.

# view.py
import pathlib

def show_board(board: Board, save_as: pathlib.Path | None = None) -> None:
    image = compute_image_for_board(board)
    cmap = ListedColormap(['w'] + [p.color for p in board.players])

    if save_as is not None:
        plt.imsave(save_as, image, cmap=cmap)

    plt.figure()
    plt.imshow(image, cmap=cmap)
    plt.show()

# spiral.py
import pathlib

if __name__ == "__main__":
    # ...
    show_board(board, save_as=pathlib.Path("result.png"))

Ce qui donne un résultat un peu plus propre.

On y est presque. Reste à pouvoir définir la configuration dans un fichier, peut-être encore un peu de refactorisation pour la forme, et puis tester ce que ça donne avec des pièces et configurations différentes !

[lien permanent]

♟2026.05.18
Spirales et chevaliers | 3. deux joueurs, et plus?

Dans la première partie, nous avons dessiné une spirale carrée. Dans la seconde, nous avons reproduit le motif de la première visualisation montrée dans la vidéo de Numberphile qui a inspiré ce petit projet. Essayons maintenant de généraliser notre code pour arriver aux formes plus complexes, avec plusieurs couleurs et déplacements.

Plusieurs joueurs

Première chose à faire: que notre générateur de points accepte une liste de joueurs. On va essayer d’avancer pas à pas, en gardant le code fonctionnel à chaque étape, donc on ne change pour l’instant rien au reste du code et on ne traite que le premier joueur de la liste:

# spiral.py
def valid_points_generator(board: Board, max_points: int, players: Iterable[Player]) -> Generator[tuple[int, int, Player], None, None]:
    n_points = 0
    player = players[0]
    # ...

if __name__ == "__main__":
    board = Board()
    player = Player(color='b', offsets=[(1, 2), (-1, 2), (2, 1), (-2, 1), (1, -2), (-1, -2), (2, -1), (-2, -1)])
    show_points(valid_points_generator(board, 1000, [player]))

Détachons ensuite la logique de “trouver le prochain point pour un joueur”, pour pouvoir itérer sur la liste des joueurs dans le générateur. Chaque joueur devra avoir son générateur de prochain point potentiel indépendant: ce n’est pas parce qu’on a passé un point et qu’il n’était pas valable pour le joueur 1 qu’il ne sera pas valable pour les autres.

# spiral.py
def _next_valid_point_for_player(points: Iterable[tuple[int, int]],
                                 board: Board,
                                 player: Player) -> tuple[int, int]:
    for x, y in points:
        if not board.is_available((x, y)): 
            continue
        if board.is_visible_from((x, y), player):
            continue
        return x, y

def valid_points_generator(board: Board, max_points: int, players: Iterable[Player]) -> Generator[tuple[int, int, Player], None, None]:
    n_points = 0
    generators = [(player, position_generator()) for player in players]
    while True:
        for player, generator in generators:
            x, y = _next_valid_point_for_player(generator, board, player)
            board.put((x, y), player)
            n_points += 1
            yield x, y, player
            if n_points >= max_points:
                return

Tout fonctionne toujours, mais le board.is_visible_from((x, y), player) n’est pas juste. Ou plutôt, ce ne sera pas juste dans la version avec plusieurs joueurs, puisqu’il faudra vérifier si la case est vue par l’un des autres joueurs.

On doit donc passer une liste de joueurs à next_valid..., et vérifier si l’on est visible de n’importe lequel d’entre eux:

# spiral.py
def _next_valid_point_for_player(points: Iterable[tuple[int, int]],
                                 board: Board,
                                 players: Iterable[Player]) -> tuple[int, int]:
    for x, y in points:
        if not board.is_available((x, y)): 
            continue
        if any(board.is_visible_from((x, y), player) for player in players):
            continue
        return x, y

Et dans le générateur, on distinguera le cas un ou plusieurs joueurs. Dans le premier cas, le point est valide s’il n’est pas visible par les cases déjà coloriée par le joueur lui-même. Dans le second, s’il n’est pas visible par les cases coloriées par l’un des autres.

# spiral.py
def valid_points_generator(board: Board, max_points: int, players: Iterable[Player]) -> Generator[tuple[int, int, Player], None, None]:
    n_points = 0
    generators = [(player, position_generator()) for player in players]
    while True:
        for player, generator in generators:
            if len(players) == 1:
                x, y = _next_valid_point_for_player(generator, board, player)
            else:
                x, y = _next_valid_point_for_player(generator, board, [p for p in players if p != player])
            board.put((x, y), player)
            n_points += 1
            yield x, y, player
            if n_points >= max_points:
                return

Mettons maintenant deux joueurs:

# spiral.py
if __name__ == "__main__":
    board = Board()
    players = [
        Player(color='r', offsets=[(1, 2), (-1, 2), (2, 1), (-2, 1), (1, -2), (-1, -2), (2, -1), (-2, -1)]),
        Player(color='k', offsets=[(1, 2), (-1, 2), (2, 1), (-2, 1), (1, -2), (-1, -2), (2, -1), (-2, -1)])
    ]
    show_points(valid_points_generator(board, 1000, players))

Et on obtient:

Ce qui, mis à part une inversion des couleurs, me semble bien correspondre à l’exemple montré dans la vidéo de Numberphile et repris sur le site de l’OEIS.

Un solide point d’arrêt pour cet article, même s’il reste du boulot.

[lien permanent]

♟2026.05.15
Spirales et chevaliers | 2. plateau et joueur

Nous sommes capables de dessiner une spirale carrée. C’est sympa, mais ce n’est pas vraiment ce dont on a besoin.

Que faire ?

On doit pouvoir répondre à la question: “quelle est la prochaine case que nous pouvons colorier”. Pour rappel, en commençant avec la version “simple” du problème, avec un seul joueur:

• La case ne doit pas encore être coloriée.
• La case ne doit pas se trouver à un déplacement de cavalier d’échec d’une case coloriée.

Notre générateur de positions sera (peut-être) utile pour la visualisation, mais il n’est certainement pas suffisant pour répondre à la question. On doit pouvoir, déjà, retenir si une case est coloriée. Vu qu’on veut pouvoir traiter une grille “infinie”, le plus pratique sera sans doute d’utiliser un dictionnaire avec comme clé la position (ou l’index de la spirale?) et comme valeur un identifiant de joueur. Ou une couleur directement. On verra ce qui est le plus utile.

Réfléchissons par l’exemple. Si je me place au début d’un tour quelconque, que dois-je faire pour trouver la prochaine case à colorier ?

• Parcourir toutes les cases (ça, je peux le faire avec mon générateur).
• Si la case est coloriée, je passe.
• Vérifier toutes les cases à un déplacement de cavalier: si l’une d’entre elle est coloriée, je passe.
• Si j’arrive ici: je colorie.

Pour pouvoir facilement vérifier les cases “à un déplacement de cavalier”, ce sera clairement plus simple en utilisant la position comme clé. Faisons donc cela.

Petite modification préalable

Notre générateur reçoit un nombre maximal de points. Mais je ne pense pas que ce sera au générateur de déterminer quand il doit s’arrêter. Je préfèrerais que ce soit décidé ailleurs. On va donc en faire un générateur infini:

def position_generator() -> Generator[tuple[int, int], None, None]:
    x, y = 0, 0
    dx, dy = 0, 0
    length = 0
    current_pos_in_segment = 0
    cycle = itertools.cycle(SPIRAL_CYCLE)
    
    while True:
        yield x, y 
        if current_pos_in_segment == length:
            direction, dl = next(cycle)
            dx, dy = direction
            length += dl
            current_pos_in_segment = 0
        x += dx
        y += dy
        current_pos_in_segment += 1

Pour l’instant, on modifie le code de visualisation pour qu’il s’arrête, lui, après 10 points:

def show_points(positions: Iterable[tuple[int, int]]) -> None:
    plt.figure()
    i = 0
    for (x1, y1), (x2, y2) in itertools.pairwise(positions):
        if i >= 10:
            break
        plt.plot(x1, y1, 'bo')
        plt.plot([x1, x2], [y1, y2], 'k-')
        i += 1
    plt.show()

Plateau de jeu

Définissons un plateau de jeu comme un dictionnaire liant un tuple (la position) à un entier (l’identifiant de son joueur / sa couleur), qui vaudra -1 si la case n’est pas coloriée. On peut utiliser un defaultdict pour se faciliter la vie, qui attribuera la valeur -1 par défaut si la clé n’existe pas.

type Board = dict[tuple[int, int], int]

# ...

if __name__ == "__main__":
    board : Board = defaultdict(default_factory=lambda: -1)

La fonction qui générera les positions à colorier devrait prendre une forme comme ceci, je crois:

def valid_points_generator(board: Board, max_points: int) -> Generator[tuple[int, int], None, None]:
    ...

Elle devra faire appel au générateur de points. Le prochain point est le premier renvoyé par le générateur qui est libre, et qui n’est pas à un déplacement de cavalier d’échec d’un point occupé. Essayons de traduire ça en code:

def valid_points_generator(board: Board, max_points: int) -> Generator[tuple[int, int], None, None]:
    offsets = [(1, 2), (-1, 2), (2, 1), (-2, 1), (1, -2), (-1, -2), (2, -1), (-2, -1)]
    n_points = 0
    for x, y in position_generator():
        if board[(x, y)] != -1: 
            continue
        if any(board[(x+dx, y+dy)] != -1 for dx, dy in offsets):
            continue
        board[(x, y)] = 1
        n_points += 1
        yield x, y
        if n_points >= max_points:
            break

On peut faire une affichage similaire à ce qu’on faisait avant, sauf qu’on ne veut pas relier les points entre eux. En fait, renommons notre ancien show_points en show_points_with_line, et réécrivons show_points:

def show_points(positions: Iterable[tuple[int, int]]) -> None:
    plt.figure()
    for x, y in positions:
        plt.plot(x, y, 'b+')
    plt.axis('equal')
    plt.show()

Le main devient:

if __name__ == "__main__":
    board : Board = defaultdict(lambda: -1)
    
    show_points(valid_points_generator(board, 100))

Ce qui nous donne l’image:

Ce qui ressemble bien à ce qu’on est supposé obtenir. Avec 1000 points:

Pas mal du tout! Mais un peu de refactorisation est nécessaire, si on veut pouvoir étendre par la suite à différentes pièces, joueurs, etc.

Plateau de jeu: objet

La première chose, c’est que je pense que le plateau de jeu mériterait d’être un objet. Je crois que cela permettra de rendre le code plus lisible. Le rôle du Board, dans un premier temps, sera de dire si une position est libre, ou visible à partir d’une série de déplacements.

# board.py
from collections import defaultdict
from typing import Iterable

class Board:
    def __init__(self):
        self.values = defaultdict(lambda: -1)
    
    def is_available(self, position: tuple[int, int]) -> bool:
        return self.values[position] == -1
    
    def is_visible_from(self, 
                        position: tuple[int, int], 
                        offsets: Iterable[tuple[int, int]]) -> bool:
        x, y = position
        return any(self.values[x+dx, y+dy] != -1 for dx, dy in offsets)
    
    def put(self, position: tuple[int, int], value: int) -> None:
        self.values[position] = value

Et dans le fichier principal — que j’appelle pour l’instant spiral.py — il faut retirer la définition du type Board et la remplacer par un import:

# spiral.py
from board import Board

On doit aussi changer le main:

# spiral.py
if __name__ == "__main__":
    board = Board()
    # ...

Et le générateur de points doit utiliser les méthodes de Board:

# spiral.py
def valid_points_generator(board: Board, max_points: int) -> Generator[tuple[int, int], None, None]:
    offsets = [(1, 2), (-1, 2), (2, 1), (-2, 1), (1, -2), (-1, -2), (2, -1), (-2, -1)]
    n_points = 0
    for x, y in position_generator():
        if not board.is_available((x, y)): 
            continue
        if board.is_visible_from((x, y), offsets):
            continue
        board.put((x, y), 1)
        n_points += 1
        yield x, y
        if n_points >= max_points:
            break

Le joueur

On peut maintenant introduire le “joueur”, qui aura une couleur et une liste de déplacements. Il n’aura, en tout cas pour l’instant, pas trop d’autre chose à faire: utilisons simplement une dataclass:

# player.py
from typing import Iterable
from dataclasses import dataclass

@dataclass
class Player:
    color: str
    offsets: Iterable[tuple[int, int]]

Cela va nous permettre de créer le joueur dans le main et de le passer, avec donc sa “configuration”, au générateur:

# spiral.py
if __name__ == "__main__":
    board = Board()
    player = Player(color='b', offsets=[(1, 2), (-1, 2), (2, 1), (-2, 1), (1, -2), (-1, -2), (2, -1), (-2, -1)])
    show_points(valid_points_generator(board, 1000, player))

Le générateur va pouvoir transmettre ce joueur au Board: c’est maintenant lui qui sera associé à une case remplie. Pour l’affichage, on va aussi renvoyer le Player en même temps que la position.

# spiral.py
def valid_points_generator(board: Board, max_points: int, player: Player) -> Generator[tuple[int, int, Player], None, None]:
    n_points = 0
    for x, y in position_generator():
        if not board.is_available((x, y)): 
            continue
        if board.is_visible_from((x, y), player):
            continue
        board.put((x, y), player)
        n_points += 1
        yield x, y, player
        if n_points >= max_points:
            break

Le Board doit maintenant utiliser ce joueur. Le dictionnaire associera maintenant un tuple à un Player, et pour rester cohérent on utilisera None comme valeur vide par défaut. is_available est changé en conséquence. is_visible_from récupère l’offset à partir du player, et vérifie spécifiquement si la case est visible par ce joueur. Cela nous permettra, je crois, d’étendre plus facilement à plusieurs joueurs par la suite.

# board.py
from collections import defaultdict
from typing import Iterable

from player import Player

class Board:
    def __init__(self):
        self.values: dict[tuple[int, int], Player | None] = defaultdict(lambda: None)
    
    def is_available(self, position: tuple[int, int]) -> bool:
        return self.values[position] is None
    
    def is_visible_from(self, 
                        position: tuple[int, int], 
                        player: Player) -> bool:
        x, y = position
        return any(self.values[x+dx, y+dy] == player for dx, dy in player.offsets)
    
    def put(self, position: tuple[int, int], player: Player) -> None:
        self.values[position] = player

Et finalement l’affichage utilisera la couleur du joueur:

# spiral.py
def show_points(positions: Iterable[tuple[int, int, Player]]) -> None:
    plt.figure()
    for x, y, player in positions:
        plt.plot(x, y, f'{player.color}+')
    plt.axis('equal')
    plt.show()

On relance le code, et tout fonctionne toujours. Ca me parait un bon endroit pour s’arrêter.

[lien permanent]

♟2026.05.13
Spirales et chevaliers | 1

Après avoir vu cette fascinante vidéo sur la chaîne Numberphile avec le Professeur Neil Sloane, j’ai eu très envie de faire mon propre générateur de visualisations, pour pouvoir tester différentes règles et configurations. Et parce que le problème a l’air intéressant. Voyons où ça nous mène.

Résumé de la vidéo

Passez directement à la section suivante si vous avez vu la vidéo, je vais juste donner un peu plus de contexte avant de commencer!

La vidéo décrit un “problème” (ou plutôt une curiosité) découverte par Jonas Karlsson. On démarre avec une grille de taille infinie, dans laquelle une case est marquée de l’indice 0. On attribue ensuite des indices croissants en formant une spirale carrée. On a donc, schématiquement, pour les dix premiers indices:

......
.432..
.501..
.6789.
......

On colore ensuite progressivement la grille en suivant la règle suivante:

Sélectionner la case avec le plus petit indice qui est:

• Libre (non-coloriée).
• Ne peut pas atteindre une case colorée via un déplacement de cavalier d’échec.

Dans le schéma ci-dessus, je pourrai donc colorier 0, 1, 2, 3 sans soucis, mais pas 4 (à un déplacement de cavalier de 1), 5 (vu par 2), 6 (vu par 3 et 1), 7 (vu par 2), 8 (vu par 3) ou 9 (vu par 0 et 2). La case libre suivante sera la case 20.

Le site de l’OEIS (l’encyclopédie des séquences entières) nous donne les premiers éléments de la séquence: https://oeis.org/A308885.

On y retrouve aussi le schéma montrant la position des cases “coloriées”, qui forme un motif régulier:

Des règles plus complexes permettent de générer des “grilles colorées” de plus en plus étranges. Par exemple, la séquence présentée dans la vidéo utilise deux “joueurs” (rouge et noir) qui colorient à tour de rôle, avec la règle: sélectionner la case avec le plus petit indice qui est libre et ne peut pas atteindre une case coloriée de l’autre couleur. La séquence se trouve également sur OEIS, et donne le schéma suivant:

D’autres exemples sont donnés dans la vidéo, avec plus ou moins de joueurs et des pièces différentes. Un tas d’illustrations pour des combinaisons de pièces différentes se trouve sur le site de Jonas Karlsson.

Objectif

On retrouve des liens vers le code de Jonas Karlsson sur le site de l’OEIS, mais je ne vais pas le regarder. Je trouve l’exercice intéressant. Mon objectif sera donc de faire un programme permettant de générer des visualisations pour:

• Un nombre de joueurs arbitraires.
• Des déplacements arbitraires (pas uniquement cavalier).
• Un nombre donné de “couches” de la spirale.

Idéalement, j’aimerais bien pouvoir partir d’une fichier de configuration simple, et générer l’image. Quelque chose comme (à raffiner)

{
    "n_layers": 10,
    "players": [
        {"color": "black", "moves": [[1, 2], [1, -2], [2, 1], [2, -1], [-2, 1], [-2, -1], [-1, 2], [-2, -2]]},
        {"color": "red", "moves": [[1, 2], [1, -2], [2, 1], [2, -1], [-2, 1], [-2, -1], [-1, 2], [-2, -2]]}
    ]
}

"moves" décrit les mouvements autorisés pour la pièce (ici, j’ai mis ceux du cavalier).

Échauffement

Je vais essayer de procéder pas à pas, en restant flexible sur la façon dont le code va s’agencer. Je suis beaucoup influencé pour l’instant par Ron Jeffries et son approche extrêmement fluide de la programmation: des petits pas, un code qui reste toujours fonctionnel, qu’on modifie très progressivement, avec un focus sur un code très clair, très expressif, bien maîtrisé. L’approche opposée du vibe coding, en somme.

Première étape: essayons simplement de dessiner la “spirale carrée”, pour commencer à comprendre et cerner le problème.

Mon premier instinct — qui n’est pas nécessairement bon! — est de faire un générateur de position, qui produit les coordonnées successives des “positions sur la grille” en suivant la spirale. Une fonction qui ferait:

from typing import Generator

def position_generator(max_n: int) -> Generator[tuple[int, int], None, None]:
    ...

Qu’on pourrait utiliser ensuite dans un main pour afficher les points reliés dans l’ordre. Juste pour tester le processus, commençons par simplement mettre les points dans l’ordre sur une droite. On fera les virages par la suite.

from typing import Generator

def position_generator(max_n: int) -> Generator[tuple[int, int], None, None]:
    x, y = 0, 0
    for _ in range(max_n):
        yield x, y
        x += 1

if __name__ == "__main__":
    for x, y in position_generator(10):
        print(x, y)

J’obtient bien:

0 0
1 0
...
9 0

L’affichage maintenant:

from typing import Generator, Iterable
from matplotlib import pyplot as plt

def show_points(positions: Iterable[tuple[int, int]]) -> None:
    plt.figure()
    for x, y in positions:
        plt.plot(x, y, 'bo')
    plt.show()


if __name__ == "__main__":
    show_points(position_generator(10))

Ce qui me donne:

Bien. Tout à l’air de fonctionner, mis à part que cela ne fait pas encore ce qu’il faut !

Comment faire pour faire “tourner” les points ? Si on regarde ce que fait la spirale carrée, on suit le processus suivant, à partir de (0, 0) et en imaginant que l’axe x va “à droite” et l’axe y va “vers le haut”:

• Avancer une fois vers la droite pour arriver en (1, 0)
• Avancer une fois vers le haut pour arriver en (1, 1)
• Avancer deux fois vers la gauche pour arriver en (-1, 1)
• Avancer deux fois vers le bas pour arriver en (-1, -1)
• Avancer trois fois vers la droite pour arriver en (2, -1)
• …

On a donc deux “cycles”: “droite”, “haut”, “gauche”, “bas”, et une augmentation de la longueur du segment tous les deux changements de direction.

C’est une bonne occasion de ressortir itertools, cet outil indispensable de la librairie standard Python. Ici, on a itertools.cycle qui nous permet de tourner entre les différentes directions à l’infini:

LEFT = (-1, 0)
RIGHT = (1, 0)
UP = (0, 1)
DOWN = (0, -1)
DIRECTION_CYCLE = [RIGHT, UP, LEFT, DOWN]

def position_generator(max_n: int) -> Generator[tuple[int, int], None, None]:
    x, y = 0, 0
    for i, direction in enumerate(itertools.cycle(DIRECTION_CYCLE)):
        if i >= max_n:
            return
        yield x, y
        dx, dy = direction
        x += dx
        y += dy
        i += 1

Maintenant, le “pas”: lorsqu’on passe de “haut” vers “gauche” et lorsqu’on passe de “bas” vers “droit”, on doit augmenter la longueur du segment. Renommons DIRECTION_CYCLE pour y ajouter cette information, et utilisons-là dans la boucle:

SPIRAL_CYCLE = [(RIGHT, 1), (UP, 0), (LEFT, 1), (DOWN, 0)]

def position_generator(max_n: int) -> Generator[tuple[int, int], None, None]:
    x, y = 0, 0
    length = 0
    for i, (direction, dl) in enumerate(itertools.cycle(SPIRAL_CYCLE)):
        if i >= max_n:
            return
        yield x, y
        length += dl
        dx, dy = direction
        x += dx*length
        y += dy*length
        i += 1

On a deux problèmes: c’est difficile de voir l’ordre des points, et on ne doit normalement pas “sauter” d’un bout du segment à l’autre comme ça. Il manque tous les points intermédiaires. Commençons par modifier la vue, toujours à l’aide de itertools, mais cette fois-ci avec itertools.pairwise pour parcourir les positions deux à deux, ce qui va me permettre de relier les points successifs.

def show_points(positions: Iterable[tuple[int, int]]) -> None:
    plt.figure()
    for (x1, y1), (x2, y2) in itertools.pairwise(positions):
        plt.plot(x1, y1, 'bo')
        plt.plot([x1, x2], [y1, y2], 'k-')
    plt.show()

Pour afficher tous les points, il faut un tout petit peu réorganiser position_generator. Au passage, je me rend compte que j’avais un i += 1 inutile en fin de boucle (puisque i était mis à jour par enumerate). De toute façon, le compteur bouge de place:

def position_generator(max_n: int) -> Generator[tuple[int, int], None, None]:
    x, y = 0, 0
    length = 0
    n_points = 1
    yield x, y
    for _, (direction, dl) in enumerate(itertools.cycle(SPIRAL_CYCLE)):
        length += dl
        dx, dy = direction
        for _ in range(length):
            if n_points >= max_n:
                return
            n_points += 1
            x += dx
            y += dy
            yield x, y

On y est. Le code n’est pas hyper lisible, cependant, essayons de rendre ça un peu plus clair. Je n’aime pas le fait d’avoir deux yield, ni les boucles imbriquées.

Mettons une seule boucle for sur le nombre de points, avec une condition pour détecter le changement de position:

def position_generator(max_n: int) -> Generator[tuple[int, int], None, None]:
    x, y = 0, 0
    dx, dy = 0, 0
    length = 0
    current_pos_in_segment = 0
    cycle = itertools.cycle(SPIRAL_CYCLE)
    
    for _ in range(max_n):
        yield x, y 
        if current_pos_in_segment == length:
            direction, dl = next(cycle)
            dx, dy = direction
            length += dl
            current_pos_in_segment = 0
        x += dx
        y += dy
        current_pos_in_segment += 1

C’est déjà mieux… et on va s’arrêter ici pour l’instant.

[lien permanent]

🟨2026.04.15
C Orienté Objet | 4

Pour faire une classe “générique” en C, on a besoin de macros. Je vais largement me baser sur l’article de Ian Fisher, Type-safe generic data structures in C, qui explique assez bien l’idée de base, sur laquelle on va pouvoir construire notre propre solution.

Cas de base

Prenons un programme très simple avec notre structure-bidon Object:

#include <stdio.h>
#include <stdlib.h>

typedef struct Object {
    int value;
} Object;


int main(){
    Object* o = malloc(sizeof(Object));
    o->value = 10;
    
    printf("%d\n", o->value);

    free(o);
}

Pour rendre Object générique, on voudrait que les int puissent être remplacés par ce qu’on veut. On va créer une macro sur base de notre typedef:

#define GEN_OBJECT(type, name)\
    typedef struct {\
        type value;\
    } name;

C’est assez dégueulasse à lire, avec les lignes qui doivent se terminer par \, mais globalement, les type et name qu’on a mis en paramètre de notre macro GEN_OBJECT vont être remplacés partout par les valeurs qu’on veut, à la compilation. Ce qui veut dire que je peux générer à la volée des structures avec les types que je veux.

Par exemple:

#include <stdio.h>
#include <stdlib.h>

#define GEN_OBJECT(type, name)\
    typedef struct {\
        type value;\
    } name;

GEN_OBJECT(int, IntObject);
GEN_OBJECT(char, CharObject);

int main(){
    IntObject* o = malloc(sizeof(IntObject));
    o->value = 10;
    
    printf("%d\n", o->value);

    CharObject* o2 = malloc(sizeof(CharObject));
    o2->value = 'd';

    printf("%c\n", o2->value);

    free(o);
    free(o2);
}

Les:

GEN_OBJECT(int, IntObject);
GEN_OBJECT(char, CharObject);

Vont être remplacés par:

typedef struct IntObject {
    int value;
} IntObject;

Et:

typedef struct CharObject {
    char value;
} CharObject;

Dans le reste du programme, on peut donc faire “comme si” on les avait définit. Pratique.

Petite subtilité qui rend la lecture du code encore plus immonde: si on veut faire une fonction qui inclut le nom de notre “variable de macro”, on doit utiliser ## pour le “coller” avec le reste du nom. Par exemple:

#define GEN_OBJECT(type, name)\
    typedef struct {\
        type value;\
    } name;\
    \
    name* name##_make(type value){\
        name* o = malloc(sizeof(name));\
        o->value = value;\
        return o;\
    }

Me permettrait de faire ensuite:

IntObject* o = IntObject_make(10);
    
printf("%d\n", o->value);

CharObject* o2 = CharObject_make('d');

printf("%c\n", o2->value);

Retour à l’ensemble

On doit maintenant récupérer tout ce qu’on avait dans notre SetObject de la dernière fois, et transformer ce Object en un paramètre. Je vais créer deux macros: une pour la déclaration de l’interface publique, et une pour l’implémentation. Ainsi, je peux garder le fait de cacher l’implémentation aux utilisateurs de la classe.

Je met la déclaration en entier:

#define DECL_SET(Object)\
    typedef struct Set##Object Set##Object;\
    Set##Object* Set##Object##_make();\
    void Set##Object##_destroy(Set##Object* set);\
    bool Set##Object##_add(Set##Object* set, Object* o);\
    bool Set##Object##_remove(Set##Object* set, Object* o);\
    bool Set##Object##_contains(Set##Object* set, Object* o);\
    int Set##Object##_size(Set##Object* set);

Et quelques morceaux choisis de l’implémentation. Tout se trouve dans un seul fichier, genericSet.h:

#define IMPL_SET(Object)\
    typedef struct Node##Object Node##Object;\
    struct Node##Object {\
        Object* obj;\
        Node##Object* next;\
    };\
    \ //...
    struct Set##Object {\
        LinkedList##Object** table;\
        int capacity;\
        int size;\
    };\
    \ // ...
    Set##Object* Set##Object##_make() {\
        Set##Object* set = malloc(sizeof(Set##Object));\
        set->capacity = 16;\
        set->size = 0;\
        set->table = malloc(sizeof(LinkedList##Object*)*set->capacity);\
        for (int i=0; i < set->capacity; i++){\
            set->table[i] = LinkedList##Object##_make();\
        }\
\
        return set;\
    }\
    \ // ...
    bool LinkedList##Object##_contains(LinkedList##Object* ll, Object* o){\
        if (ll->size == 0){\
            return false;\
        } else {\
            Node##Object* node = ll->first;\
            while (node != NULL){\
                if (Object##_equals(node->obj, o)){\
                    return true;\
                }\
                node = node->next;\
            }\
            return false;\
        }\
    }\
// ...

Toute cette complexité n’est pas en vain, cependant, car elle me permet maintenant dans set.h de faire:

#include <stdbool.h>
#include "genericSet.h"

typedef struct Object Object;
Object* Object_make(int value);
void Object_destroy(Object* o);
int Object_hash(Object* o);
int Object_equals(Object* o, Object* other);

DECL_SET(Object)

Et dans set.c de faire:

#include <stdbool.h>
#include <stdlib.h>
#include <stdio.h>
#include "set.h"

// for testing
struct Object {
    int value;
};
Object* Object_make(int value){ 
    Object* o = malloc(sizeof(Object));
    o->value = value;
    return o;
}
void Object_destroy(Object* o){ free(o); }
int Object_hash(Object* o){ return o->value; }
int Object_equals(Object* o, Object* other){ return o->value == other->value; }

IMPL_SET(Object)

Pour que tous mes tests précédents fonctionnent. Dans mon fichier de test, je peux inclure set.h et avoir accès à toutes les méthodes de SetObject.

Un set de personnes?

Voyons si on peut grâce à tout ce travail se faire, enfin, un ensemble de Person. J’aurai besoin de créer une méthode Person_hash pour que ça fonctionne. Vu que Person est composé de chaînes de caractères, je vais utiliser une méthode de hachage appropriée. J’ai trouvé cet article qui traduit un article d’un site russe que mon navigateur me déconseille d’ouvrir, donc ça doit être de la qualité. On nous dit que, pour hacher une chaîne de caractères, on doit faire:

s[0] + s[1]*p + s[2]*(p^2) + ... + s[n-1]*(p^{n-1}) % m

Avec une valeur de p conseillée de 31. OK, essayons. Modulo une valeur arbitraire. L’article propose un “nombre premier large”, comme 10^9 + 9. Why not.

On a:

// person.c
#define HASH_P 31
#define HASH_MOD pow(10, 9)+9

// ...

int Person_hash(Person* p) {
    int h = 0;
    for (int i = 0; i < strlen(p->first_name); i++){
        h += p->first_name[i]*pow(HASH_P, i);
    }
    for (int i = 0; i < strlen(p->last_name); i++){
        h += (p->first_name[i]+strlen(p->first_name))*pow(HASH_P, i);
    }

    return h % HASH_MOD;
}

Rajoutons dans notre fichier de test un test très simple:

bool test_person_hash(){
    Person* p = Person_make("abcd", "efgh");
    Person* p2 = Person_make("efgh", "abcd");
    Person* p3 = Person_make("abcd", "efgh");

    bool result = !(Person_hash(p)==Person_hash(p2)) &&
                   (Person_hash(p)==Person_hash(p3));
}

Je m’attends à des erreurs de typage, je ne me suis pas trop préoccupé des castings dans toutes mes opérations. J’en ai une, sur le modulo.

// ...
    return h % ((int) HASH_MOD);

Le test passe. Je ne suis pas sûr que tout est en ordre, mais ce sera suffisant pour le moment.

L’important, c’est que je devrais pouvoir créer un personSet.h avec:

#include <stdlib.h>
#include "set.h"
#include "person.h"

DECL_SET(Person)

Et un fichier personSet.c avec:

#include "personsSet.h"

IMPL_SET(Person);

Et rajouter un test:

#include "personsSet.h"
// ...
bool test_person_set(){
    SetPerson* set = SetPerson_make();
    Person* p = Person_make("abcd", "efgh");
    Person* p2 = Person_make("efgh", "abcd");

    SetPerson_add(set, p);

    bool result = SetPerson_contains(set, p) && !SetPerson_contains(set, p2);

    SetPerson_destroy(set);
    Person_destroy(p);
    Person_destroy(p2);
}

Et, mis à part le fait que je me suis un peu emmêlé les pinceaux dans mes conventions de nommage et qu’il va falloir que je change un peu tout ça entre mes SetPerson et mes personSet… ça fonctionne!

Je suis assez impressionné, je dois dire.

Renommons donc personSet.h et personSet.c en setPerson, et on arrive à quelque chose de tout à fait fonctionnel. Je m’attendais à beaucoup plus devoir me casser la tête. Tant mieux !

Conclusion

Je pense que je vais m’arrêter là, pour le moment en tout cas, dans cette exploration du C orienté objet. On pourrait évidemment aller beaucoup plus loin. On n’a pas ici d’héritage, pas de polymorphisme, pas de pleins de choses que les langages orientés objets aiment faire. Mais on pourrait y arriver. Après tout, Python permet de faire de l’orienté objet, et le langage est écrit en C. Il faut bien que ces fonctionnalités viennent de quelque part !

[lien permanent]

🟨2026.04.13
C Orienté Objet | 3

Avec une Person et une PersonsTable, nous avons les prémisses d’un programme “orienté objet”. Peut-on aller un peu plus loin? Pour ça, je pense qu’il est temps de penser à une petite application qui nous permettra de tester les limites de ce qu’on peut faire sans devoir se casser déraisonnablement la tête.

Idée: un annuaire

J’imagine un menu:

=== Choose option ===

[1] Add new contact
[2] Remove contact
[3] List all contacts
[4] List all groups
[5] List contacts in group
[0] Quit

On doit pouvoir lister, ajouter et supprimer des “contacts” pour des personnes, qui auraient un nom, un prénom, un email et un numéro de téléphone, et qu’on peut rassembler en groupes qui, eux-même, ont un nom unique. La combinaison nom-prénom-email-numéro de téléphone doit, elle aussi, être unique. Un contact peut être dans plusieurs groupes, ou dans aucun.

On devrait donc avoir une structure de type:

AddressBook
    - Groups
    - Contacts

Group
    - Contacts

Contact
    - firstName
    - lastName
    - email
    - phoneNumber
    - Groups

J’ai mis beaucoup de critères d’unicité dans cette description, ce qui signifie qu’on aurait bien besoin d’une notion d’ensemble. Ca tombe bien, je viens de voir les ensemble dans le cours de structures de données que je donne. Voyons-voir: est-ce qu’on peut se créer une “classe ensemble” générique, à partir de laquelle on va pouvoir faire des ensembles de groupes et des ensembles de contacts ?

Aucune idée, mais ça se tente. Essayons déjà de faire un ensemble d’une chose: des objets bidons.

Ensemble d’objets

Je définis, juste pour avoir quelque chose à mettre, un Object contenant une valeur sous forme d’int:

// set.h
typedef struct Object Object;

// set.c
struct Object {
    int value;
};

Et, puisqu’on est avec des objets, on a besoin de ses méthodes:

// set.c
Object* Object_make(int value){ 
    Object* o = malloc(sizeof(Object));
    o->value = value;
    return o;
}
void Object_destroy(Object* o){ free(o); }

Jusque là, rien de bien intéressant. Pour gérer des ensembles, je vais essayer d’implémenter une “table de hachage”. Pour chaque objet, on doit pouvoir calculer un “hash code”, et avoir une notion d’égalité:

int Object_hash(Object* o){ return o->value; }
int Object_equals(Object* o, Object* other){ return o->value == other->value; }

C’est ce qui va permettre d’avoir un accès aux objets en O(1) (si tout va bien) dans l’ensemble. Celui-ci devra avoir l’interface suivante:

// set.h
typedef struct SetObject SetObject;

SetObject* SetObject_make();
void SetObject_destroy(SetObject* s);
bool SetObject_add(SetObject* s, Object* p);
bool SetObject_remove(SetObject* s, Object* p);
bool SetObject_contains(SetObject* s, Object* p);
int SetObject_size(SetObject* s);

On retrouve tout ce qu’on avait dans les tables avant, mais maintenant on va l’implémenter avec une table de hachage et on va garantir l’unicité.

L’idée avec la table de hachage est qu’on garde un tableau dans lequel on met des listes chaînées contenant les éléments de l’ensemble. Soit un objet ayant le hash code N, si le tableau a une taille T, on ajoutera l’élément dans la liste liée située en table[N%T]. Imaginons 5 éléments avec les hash code 1, 3, 6, 4, 7 dans une table de taille 6. On aura:

table[0] -> [6]
table[1] -> [1] -> [7]
table[2] -> []
table[3] -> [3]
table[4] -> [4]
table[5] -> []

Pour faire une liste chaînée, on doit introduire une notion de “noeud”, qui contiennent un élément ainsi qu’un pointeur vers l’élément suivant. En complétant l’exemple précédent, on a:

table[0] -> N[6, [/]]
table[1] -> N[1, [-> N[7, [/]]]]
table[2] -> [/]
table[3] -> N[3, [/]]
table[4] -> N[4, [/]]
table[5] -> [/]

Ou [/] représente un pointeur NULL.

En C, on aura donc des noeuds:

typedef struct NodeObject NodeObject;
struct NodeObject {
    Object* obj;
    NodeObject* next;
};

Et une liste chaînée:

typedef struct {
    NodeObject* first;
    int size;
} LinkedListObject;

Qui nous amène à notre ensemble:

struct SetObject {
    LinkedListObject** table;
    int capacity;
    int size;
};

SetObject aura donc une liste de pointeurs vers des LinkedListObject, qui eux-même contiennent un pointeur vers leur premier NodeObject, qui contient un pointeur vers le suivant, etc.

Comment créer notre Set? On doit allouer de la mémoire pour le SetObject, fixer sa capacité initiale, allouer de la place pour les pointeurs vers des LinkedListObject et, pour chacun de ces LinkedListObject, on doit allouer de l’espace en mémoire et initialiser la taille à 0 et le pointeur de tête à NULL.

LinkedListObject* LinkedListObject_make(){
    LinkedListObject* ll = malloc(sizeof(LinkedListObject));
    ll->size = 0;
    ll->first = NULL;
    return ll;
}

SetObject* SetObject_make() {
    SetObject* set = malloc(sizeof(SetObject));
    set->capacity = 16;
    set->size = 0;
    set->table = malloc(sizeof(LinkedListObject*)*set->capacity);
    for (int i=0; i < set->capacity; i++){
        set->table[i] = LinkedListObject_make();
    }

    return set;
}

Il faut aussi prévoir de pouvoir créer des noeuds:

NodeObject* NodeObject_make(Object* o, NodeObject* next){
    NodeObject* node = malloc(sizeof(NodeObject));
    node->obj = o;
    node->next = next;
    return node;
}

Lorsqu’on détruit un SetObject, il faudra détruire les LinkedListObject, qui elles-même devront détruire les NodeObject.

void NodeObject_destroy(NodeObject* node){
    if (node->next != NULL)
        NodeObject_destroy(node->next);
    free(node);
}

void LinkedListObject_destroy(LinkedListObject* ll){
    if (ll->size > 0)
        NodeObject_destroy(ll->first);
    free(ll);
}

void SetObject_destroy(SetObject* set){
    for (int i=0; i < set->capacity; i++)
        LinkedListObject_destroy(set->table[i]);
    free(set);
}

Pour rajouter un objet, il faut:

• Calculer son hash code
• En déduire la position dans la table
• Vérifier si la liste liée contient déjà l’élément
• Sinon: le rajouter

On renvoie un booléen à la fin pour savoir si on a pu ajouter l’élément ou non.

bool LinkedListObject_add(LinkedListObject* ll, Object* o){
    if (ll->size == 0){
        // Empty list -> add to the front
        ll->first = NodeObject_make(o, NULL);
        ll->size++;
        return true;
    } else {
        // Go through the list. If we haven't found it at the end, 
        // we can connect it to the last non-null element we found.
        NodeObject* node = ll->first;
        NodeObject* prev = NULL;
        while (node != NULL){
            if (Object_equals(node->obj, o))
                return false;
            prev = node;
            node = node->next;
        }
        // if we're here, we are at the end of the list and we 
        // haven't found the object, so we can add it.
        prev->next = NodeObject_make(o, NULL);
        ll->size++;
        return true;
    }
}

bool SetObject_add(SetObject* set, Object* o){
    int h = Object_hash(o) % set->capacity;
    if (LinkedListObject_add(set->table[h], o)){
        set->size++;
        return true;
    }
    return false;
}

Le retrait se fait de manière très semblable. S’il n’y a rien, on n’a rien à retirer. Sinon, on cherche l’objet. Pour le retirer, on connecte le noeud précédent l’objet au noeud suivant l’objet. On peut aussi retirer le NodeObject de la mémoire. On n’appelle pas NodeObject_destroy car celui-ci est prévu pour aussi aller détruire tout ce qui suit de manière récursive, ce qu’on ne veut pas voir ici comme comportement. Si on n’a pas trouvé l’objet à la fin, c’est qu’on ne peut pas le retirer.

bool LinkedListObject_remove(LinkedListObject* ll, Object* o){
    if (ll->size == 0){
        return false;
    } else {
        NodeObject* node = ll->first;
        NodeObject* prev = NULL;
        while (node != NULL){
            if (Object_equals(node->obj, o)){
                if (prev == NULL)
                    ll->first = node->next;
                else
                    prev->next = node->next;
                free(node);
                ll->size--;
                return true;
            }
            prev = node;
            node = node->next;
        }
        return false;
    }
}

bool SetObject_remove(SetObject* set, Object* o){
    int h = Object_hash(o) % set->capacity;
    if (LinkedListObject_remove(set->table[h], o)){
        set->size--;
        return true;
    }
    return false;
}

Pour savoir si l’ensemble contient un objet, on reste dans la même logique:

bool LinkedListObject_contains(LinkedListObject* ll, Object* o){
    if (ll->size == 0){
        return false;
    } else {
        NodeObject* node = ll->first;
        while (node != NULL){
            if (Object_equals(node->obj, o)){
                return true;
            }
            node = node->next;
        }
        return false;
    }
}

bool SetObject_contains(SetObject* set, Object* o){
    int h = Object_hash(o) % set->capacity;
    return LinkedListObject_contains(set->table[h], o);
}

Et renvoyer la taille ne pose pas trop de difficultés:

int SetObject_size(SetObject* set){
    return set->size;
}

Conclusion

Nous avons maintenant une notion d’un “ensemble” pour un objet “bidon”, Object. A priori, adapter cet ensemble à n’importe lequel de nos objets (comme Person, ou le futur Group) devrait être raisonnablement simple. Il faut:

• Modifier toutes les références à Object.
• S’assurer que l’on dispose de méthodes _hash et _equals pour l’objet que l’on désire mettre dans un ensemble.

Et si on veut éviter les copier-coller foireux… on va devoir s’intéresser aux macros. Je n’en ai jamais fait: il va me falloir un peu de lecture d’abord.

[lien permanent]

🟨2026.04.03
C Orienté Objet | 2

Nous avons lors du premier épisode créé une “classe” Person, mais elle se sent bien seule. Les objets sont fait pour communiquer, avoir des relations, s’envoyer des messages. Pour l’instant, nous n’avons rien de tout ça. Commençons.

Une table de personnes

Je voudrais avoir un tableau de personnes, avec la possibilité d’y ajouter et d’en retirer des éléments, de supprimer ou récupérer des éléments par leur index, de savoir si la table contient une certaine personne, et d’en afficher le contenu. On a du boulot. Commençons par écrire personsTable.h pour définir tout ça proprement:

#include <stdbool.h>
#include "person.h"

typedef struct PersonsTable PersonsTable;

PersonsTable* PersonsTable_make();
void PersonsTable_destroy(PersonsTable* t);
void PersonsTable_add_person(PersonsTable* t, Person* p);
bool PersonsTable_remove(PersonsTable* t, int idx);
Person* PersonsTable_get(PersonsTable* t, int idx);
bool PersonsTable_contains(PersonsTable* t, Person* p);
void PersonsTable_print(PersonsTable* t);

Il y a de nombreuses façons d’implémenter ces fonctionnalités. L’idée est donc ici que les utilisateurs de ma “classe” ne devront pas s’en préoccuper. Et si je veux changer, ça ne devrait pas les affecter.

En particulier, j’ai deux grands choix à faire ici:

• Quelle structure de donnée utiliser pour la “table”?
• Quelle est la définition de l’égalité pour mes Personnes (c’est-à-dire: comment je détermine si ma table contient une certaine Personne).

Cette seconde question va me faire évoluer la classe Person. Commençons par là.

Égalité des personnes

Je dois rajouter une méthode dans person.h:

bool Person_equals(Person* p, Person* other);

Et évidemment l’implémenter dans person.c. Je peux utiliser strcmp pour comparer des chaînes de caractères. Je prendrai donc la définition de l’égalité ici comme: “a le même nom et le même prénom”. J’aurais pu à la place choisir de vérifier si l’adresse des deux objets en mémoire était la même, mais ce serait fort limitant. Évidemment, dans un vrai système, j’aurais besoin de quelque chose de plus “identifiant” que le nom et le prénom, mais on va rester simple pour l’instant. strcmp compare deux chaînes de caractères (“null-terminated”, c’est-à-dire qu’il y a un caractère nul \0 pour marquer la fin), et renvoie 0 si tous les caractères sont les mêmes.

bool Person_equals(Person* p, Person* other) {
    return (strcmp(p->first_name, other->first_name)==0 && 
            strcmp(p->last_name, other->last_name)==0);
}

Testons dans le main:

Person* p = Person_make("Adrien", "Foucart");
Person* other = Person_make("Adrien", "Foucart");
Person_print(p);
Person_print(other);
if (Person_equals(p, other)){
    printf("Persons are equal.\n");
}
else {
    printf("Persons are not equal.\n");
}
Person_destroy(p);
Person_destroy(other);

Je reçois bien Persons are equal. Et si je change une lettre à mon nom, j’ai bien unequal. Tout va bien! Revenons à notre table.

Tableau redimensionnable

Une manière classique de réaliser une table est le principe du “tableau redimensionnable”. Il implique de garder en parallèle une “taille physique” (espace mémoire occupé par la table) et une “taille logique” (nombre d’éléments dans la table). Lorsque la taille logique rattrape la taille physique, on agrandit la table (généralement en la doublant). On traduit ça dans notre struct PersonsTable:

// personsTable.c
struct PersonsTable {
    Person** table;
    int capacity;
    int size;
};

Le constructeur devra donc donner une capacité initiale à la table, et une taille logique (size) de 0. Notons le “double pointeur” pour table. Schématiquement, j’ai:

[table] --> Addr: 0x1234 (exemple)
[0x1234] --> [Person a]
[0x1235] --> [Person b]
[0x1236] --> [Person c]

table pointe vers l’adresse du premier élément du tableau, qui se trouve quelque part dans la mémoire du programme. Ce premier élément est lui-même un pointeur vers une Person. L’élément suivant dans la mémoire sera le pointeur vers la personne suivante, etc. Au niveau du constructeur, j’aurai alors:

PersonsTable* PersonsTable_make(){
    PersonsTable* pt = malloc(sizeof(PersonsTable));
    pt->size = 0;
    pt->capacity = 16;
    pt->table = malloc(sizeof(Person*)*pt->capacity);
    return pt;
}

J’ai deux malloc dans le constructeur, j’aurai donc besoin de deux free dans le destructeur:

void PersonsTable_destroy(PersonsTable* t) {
    free(t->table);
    free(t);
}

Notons un choix fait ici: je ne libère pas les Person. Elles n’ont pas été construites par la classe table, donc elles peuvent exister ailleurs dans le programme. Ce n’est pas la responsabilité de PersonsTable de s’en préoccuper.

Quand on ajoute une personne, on doit d’abord vérifier si on ne doit pas allonger la table (avec realloc). Et il ne faut pas oublier d’incrémenter la taille.

void PersonsTable_add_person(PersonsTable* t, Person* p) {
    if (t->size == t->capacity){
        t->capacity *= 2;
        t->table = realloc(t->table, t->capacity);
    }
    t->table[t->size++] = p;
}

Pour retirer une personne, il faut s’assurer que l’index est valide. On retire une personne en décalant les éléments suivants vers la gauche. On renvoie un booléen pour indiquer si l’opération a réussit. Et on n’oublie pas de décrémenter la taille.

bool PersonsTable_remove(PersonsTable* t, int idx) {
    if (idx < 0 || idx >= t->size)
        return false;

    for (int i = idx; i < t->size - 1; i++)
        t->table[i] = t->table[i+1];

    t->size--;
    return true;
}

Récupérer un élément est assez simple. On renvoie NULL si l’index n’est pas valide:

Person* PersonsTable_get(PersonsTable* t, int idx) {
    if (idx < 0 || idx >= t->size)
        return NULL;

    return t->table[idx];
}

Pour savoir si notre table contient un élément, on n’a pas trop le choix: il faut les parcourir tous. Je ne prétends pas ici à une grande efficacité!

bool PersonsTable_contains(PersonsTable* t, Person* p) {
    for (int i = 0; i < t->size; i++){
        if (Person_equals(p, t->table[i]))
            return true;
    }

    return false;
}

Et finalement on veut pouvoir les afficher:

void PersonsTable_print(PersonsTable* t) {
    printf("[PersonsTable]:\n");
    for (int i=0; i < t->size; i++){
        printf("\t");
        Person_print(t->table[i]);
    }
}

Important ici: pour ces deux dernière méthodes, nous avons fait appel aux méthodes de Person. Des objets qui s’envoient des messages, comme il faut!

Reste à tester que ça fonctionne.

int main(){
    printf("Start program\n");

    // Create test persons
    Person* p = Person_make("Adrien", "Foucart");
    Person* other = Person_make("Leonardo", "Da Vinci");

    // Create and fill table
    PersonsTable* pt = PersonsTable_make();
    PersonsTable_add_person(pt, p);
    PersonsTable_add_person(pt, other);

    PersonsTable_print(pt);
    
    // check contains method
    if (PersonsTable_contains(pt, p)){
        printf("Table contains person: ");
        Person_print(p);
    }

    // check get method
    Person* found = PersonsTable_get(pt, 1);
    Person_print(found);

    // check remove
    PersonsTable_remove(pt, 0);
    PersonsTable_print(pt);
    
    if (!PersonsTable_contains(pt, p)){
        printf("Table does not contain person: ");
        Person_print(p);
    }

    PersonsTable_destroy(pt);
    Person_destroy(p);
    Person_destroy(other);

    printf("End program\n");
    return 0;
}

Ce qui me donne:

[PersonsTable]:
        [Person]: Adrien Foucart
        [Person]: Leonardo Da Vinci
Table contains person: [Person]: Adrien Foucart
[Person]: Leonardo Da Vinci
[PersonsTable]:
        [Person]: Leonardo Da Vinci
Table does not contain person: [Person]: Adrien Foucart
End program

Un peu de recul

Qu’avons-nous jusqu’à présent?

• Des objets qui offrent des interfaces publiques et disposent d’attributs privés.
• Des objets qui sont responsables des opérations qui les concernent, et peuvent déléguer du travail en envoyant des messages.

C’est déjà pas mal, pour une poignée de lignes de code!

Mais j’ai l’impression qu’on peut aller un peu plus loin. Une prochaine fois.

[lien permanent]

🟨2026.04.01
C Orienté Objet | 1

Le C n’est généralement pas un langage associé à la programmation orientée objet. Quand j’ai appris le C++, on me l’a initialement un peu présenté comme “du C mais avec des objets”, et c’est comme ça que j’ai généralement regardé ces langages (que j’utilise très peu) jusqu’à présent.

Mais en “jouant” à résoudre les vieux puzzles Advent of Code en C (voir mes notes à ce sujet!), je me suis rendu compte que je commençais à utiliser naturellement des principes “orienté objet” dans mes résolutions. On a parfois je pense (en tout cas moi!) un peu tendance à réduire “orienté objet” à “on peut déclarer des classes”. Mais on peut avoir des classes et des objets sans faire de la programmation orientée objet (beaucoup de projets Python en sont un bon exemple!), et on peut faire de la programmation orientée objet sans classes. Car au-delà de la syntaxe, c’est surtout dans la façon d’organiser et de penser son code que les concepts orientés objets apparaissent.

Et après tout, beaucoup de langages “orientés objets” sont écris en C, donc c’est nécessairement possible d’en faire en revenant à la source!

Essayons.

Une classe Person

Commençons par un classique: une classe Person, qui contiendrait un nom et un prénom. Nous n’avons pas de “classes” en C, mais on peut déclarer des structures:

struct Person {
    char* first_name;
    char* last_name;
};

Ici, on a donc bien une Person qui possède un first_name et un last_name. Si je veux l’utiliser dans mon code, je pourrais faire quelque chose comme ceci:

struct Person* p = malloc(sizeof(struct Person));
p->first_name = "Adrien";
p->last_name = "Foucart";
printf("%s %s\n", p->first_name, p->last_name);
free(p);

Avec malloc, j’alloue dans ma mémoire l’espace pour mes deux pointeurs, que je fais pointer vers des chaînes de caractère.

Dans une logique “orientée objet”, cependant, je ne veux pas que ces détails d’implémentation de ma classe (comme le nom des attributs) soient connus. Je voudrais idéalement ne manipuler que des méthodes “publiques”.

On va donc commencer par créer deux fichiers: person.c et person.h. Dans person.h, nous allons mettre nos déclarations publiques:

// person.h
typedef struct Person Person;

Person* Person_make(char* first_name, char* last_name);
void Person_destroy(Person* p);
void Person_print(Person* p);

Je prévois ici trois méthodes: un constructeur, un destructeur, et une méthode pour afficher le contenu de l’objet. Avec typedef struct Person Person, on permet de ne pas retaper struct Person à chaque fois en lui donnant un “alias” Person.

L’implémentation, maintenant, va se trouver dans person.c, et sera invisible pour les utilisateurs de person.h:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "person.h"

struct Person {
    char* first_name;
    char* last_name;
};

Person* Person_make(char* first_name, char* last_name){
    Person* p = malloc(sizeof(Person));
    p->first_name = malloc(strlen(first_name)+1);
    p->last_name = malloc(strlen(last_name)+1);
    strcpy(p->first_name, first_name);
    strcpy(p->last_name, last_name);

    return p;
}

void Person_destroy(Person* p) {
    free(p->first_name);
    free(p->last_name);
    free(p);
}

void Person_print(Person* p) {
    printf("[Person]: %s %s\n", p->first_name, p->last_name);
}

Dans le constructeur, on alloue de l’espace pour les chaînes de caractères des noms et prénoms, que l’on copie. On ne veut pas juste copier les pointeurs, sinon celui qui appelle Person_make pourrait ensuite changer la valeur de p->first_name, ou faire un free dessus. Dans le destructeur, on fait le ménage.

Pour utiliser tout ceci, écrivons un main.c:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "person.h"

int main(){
    printf("Start program\n");

    Person* p = Person_make("Adrien", "Foucart");
    Person_print(p);
    Person_destroy(p);

    printf("End program\n");
    return 0;
}

Ce main n’a plus aucune visibilité sur ce que contient Person. Si j’essaie d’ajouter printf("%s\n", p->first_name);, j’ai une erreur de compilation, car person.h ne contient pas de détail sur les “attributs” de Person. Je ne peux les utiliser qu’à travers ses méthodes.

Autrement dit: Person se comporte maintenant comme un “objet” qui, par exemple en Java, s’écrirait¹:

public class Person {
    private String first_name;
    private String last_name;

    public Person(String first_name, String last_name){
        this.first_name = first_name;
        this.last_name = last_name;
    }

    public void print(){
        System.out.println("[Person]: " + first_name + " " + last_name);
    }
}

On ne va pas encore très loin dans le concept, mais je dirais que ça compte, comme premier pas. Pour la suite… on verra dans les épisodes suivants!

[lien permanent]

⏩2026.03.30
auto-complétion

Durant les séances d’exercice, je me retrouve souvent à réfléchir au rôle que joue l’auto-complétion, et plus généralement les outils de génération de code, dans la pratique de la programmation. Car c’est, je pense, l’un des nombreux domaines où les dommages causés par l’IA générative se fait fortement ressentir.

L’auto-complétion “traditionnelle” fonctionne est simple et largement déterministe: étant donné les éléments présents dans le scope et les premières lettres entrées par l’utilisateur, déterminer quels sont les possibilités de complétion et (seule partie probabiliste) les trier selon leur pertinence. Les outils de génération, eux-aussi, sont (étaient) simple: étant donné un template paramétrable, et une série de paramètres, générer un ou des blocs de code.

Simple, mais puissant. Il y a plus de dix ans maintenant, je l’utilisais pour générer des dizaines de classes à la volée en Java sur base d’un schéma de base de données. Tout le boilerplate répétitif de la création de classes “modèles” et “contrôleurs” était fait, on pouvait se concentrer sur la logique de plus haut niveau du programme.

Et l’auto-complétion classique, en plus d’être un gain de temps, est aussi un formidable outil d’apprentissage et de découverte. Quelles sont les méthodes disponibles depuis cette classe? Tape un ., appuie sur TAB (ou Ctrl-Espace selon les IDEs, en général), et fait défiler tout l’univers des possibilités. Cette auto-complétion fonctionne au rythme du développeur et encourage la réflexion et la remise en question. Il m’est régulièrement arrivé de m’arrêter, intrigué par une proposition de méthode que je ne connaissais pas, de lire rapidement la documentation, et de me rendre compte d’une possibilité que je n’avais pas envisagée pour remplir les besoins de mon programme.

Le code généré, quand à lui, ne nécessitait pas vraiment de relecture. Une fois qu’on avait compris le principe de comment configurer le template, on pouvait être certain que le résultat serait toujours exact, et on garde une compréhension aussi complète que possible de ce qui se trouve dans le code du projet.

Les IAs génératives nous privent de tous ces bénéfices, et ne visent plus qu’à l’objectif de productivité à court terme: produire plus de lignes de codes, maintenant, tout de suite.

L’étudiant.e écrit if, et l’IA propose immédiatement un bloc if-else complet qui fait quelque chose, quelque chose qui à première vue semble toujours logique par rapport à ce qui leur est demandé. Parfois, on peut résoudre un exercice complet à coup de TAB-TAB-TAB jusqu’à ce que tous les tests passent.

On ne sait pas ce qu’il y a dans le code. On ne sait pas pourquoi ça marche. Quand finalement ça ne marche plus, on n’a pas la moindre idée de par où commencer.

Vécu récemment: un.e étudiant.e m’appelle, me montre son code.

– Monsieur, je ne comprends pas ce qu’il se passe.
– Qu’est-ce qui ne marche pas?
– Ca marche, mais je ne comprends pas pourquoi il faut écrire ça.
– Pourquoi tu l’as écrit? Qu’est-ce que tu cherchais à faire?
– …

Je peux alors expliquer le pourquoi, mais la qualité de l’apprentissage n’est jamais la même. On apprend en faisant. Avec l’IA générative, l’étudiant.e ne fait pas, il relit ce que l’IA a fait et pense le comprendre.

Heureusement, iels sont nombreux.ses à s’en rendre compte. Beaucoup m’appellent pour me demander de l’aide pour couper les aides IA. Ils voient bien qu’ils n’apprennent pas. Mais ces outils reviennent, se réactivent, se réinstallent à chaque mise à jour. Ce sont des mauvaises herbes dont ils peinent à se débarrasser. Et la tentation est toujours présente, quand la charge de travail devient un peu trop élevée, lorsqu’on se sent un peu trop largué, lorsqu’on est coincé alors que l’enseignant.e est occupé.e avec d’autres et qu’on a envie d’avancer.

L’utilisation des IAs génératives brident l’apprentissage. C’est dramatique pour les étudiant.es, c’est problématique même pour les développeur.euses aguerri.es. J’ai beaucoup appris durant cette première année en tant qu’enseignant, à donner des cours dans des matières qui ne sont pas nécessairement les miennes. Je suis un meilleur développeur aujourd’hui que je ne l’étais il y a un an. Et je le dois, je crois, au fait que je me suis forcé à toujours faire les choses moi-même, à faire tous (ou presque) les exercices qu’on demande aux étudiant.es de faire, à me donner des petits projets pour aller plus loin. Et toujours j’ai cherché à avancer à petits pas, en comprenant à chaque étape ce que je faisais et pourquoi je le faisais.

Serais-je allé plus vite avec Claude à mes côtés? Peut-être. Mais j’en serais sorti diminué. Au fur et à mesure des années, je suis persuadé que celleux qui se reposent sur Claude et ses amis seront de moins en moins compétents, de moins en moins capable de réfléchir, de moins en moins capable de penser une solution. Je crois qu’aujourd’hui déjà, et certainement demain après l’éclatement de la bulle spéculative des IAs génératives, être capable de développer sans agent à mes côtés est une compétence qui n’a pas de prix.

[lien permanent]

🛑2026.02.07
java test runner

Les tests unitaires en Java semblent assez désagréable à mettre en place. Le framework le plus utilisé semble être JUnit, et à première vue ça me semble un peu “usine à gaz”. Il y a aussi visiblement eu de gros changements entre les versions, et les tutoriels que j’ai trouvé sont pour la plupart obsolètes.

Mes besoins en tests unitaires sont assez limités. Je ne compte pas faire des tonnes de réflexion, de mocking ou autres joyeusetés. Je voudrais juste pouvoir facilement créer des classes de test, et avoir un point d’entrée d’où je peux tous les lancer automatiquement. Ca ne devrait pas nécessiter de faire tout un setup Maven ou Gradle et d’importer des jar dans tous les sens.

On va voir: faisons un petit “test runner” Java en utilisant uniquement la librairie standard.

Première étape: les tests à tester

Dans mon dossier src, où j’aurais dans un projet les “vraies” classes développées, mettons un dossier Test et créons une classe TestTest qui servira à tester le test runner. Rien de confus jusqu’à présent.

package Test;

public class TestTest {
    public static void testSuccess(){
        assert true : "if this fails, we are in trouble.";
    }

    public static void testFailed(){
        assert false : "test has failed successfully!";
    }
}

On met deux tests dedans: le premier devrait réussir, le second échouer.

Deuxième étape: lancer les tests

Ajoutons maintenant une classe TestRunner, avec une méthode main. C’est ici que toute la partie intéressante doit se passer. Commençons simplement et laissons de côté la partie “découverte des classes et méthodes de test” pour juste lancer les deux tests et vérifier que tout se passe comme prévu.

package Test;

public class TestRunner {
    public static void main(String[] args){
        TestTest.testSuccess();
        TestTest.testFailed();
    }
}

On lance… et rien ne se passe. Petit moment de recherche: par défaut, les assertions en Java sont désactivées. Pour qu’elles aient de l’effet, il faut aller modifier le DefaultAssertionStatus du ClassLoader:

public class TestRunner {
    public static void main(String[] args){
        ClassLoader loader = ClassLoader.getSystemClassLoader();
        loader.setDefaultAssertionStatus(true);

        TestTest.testSuccess();
        TestTest.testFailed();
    }
}

On relance:

Exception in thread "main" java.lang.AssertionError: test has failed successfully!

Parfait.

On continue: trouver les méthodes dans une classe

La classe Class permet de récupérer les méthodes qui existent dans une classe donnée. Imaginons donc qu’on a une liste de “classes de test”. On peut parcourir ces classes et récupérer leurs méthodes:

public class TestRunner {
    private static String[] testClasses = {"TestTest"};

    public static void main(String[] args){
        // ...
        for (String c: testClasses){
            try {
                Class testClass = Class.forName(c);
                Method[] methods = testClass.getDeclaredMethods();
                for (Method m : methods) {
                    System.out.println(m.getName());
                }
            } catch (ClassNotFoundException e) {
                System.err.println("Class not found: " + c);
                return;
            }
        }
    }

Ce qui me donne…

Class not found: TestTest

Effectivement, le “nom” de la classe doit inclure le nom du package:

    // ...
    private static String[] testClasses = {"Test.TestTest"};
    // ...

On a maintenant:

testSuccess
testFailed

Parfait.

Invoquer les méthodes et récupérer les exceptions

Reste à invoquer la méthode, ce qu’on fait avec evoke:

public class TestRunner {
    // ...
    public static void main(String[] args){
        // ...
            for (Method m : methods) {
                m.invoke(null);
            }
        // ...
    }

Mon IDE me signale que je dois traiter des possibles IllegalAccessException et InvocationTargetException. La première peut arriver si la méthode que je cherche à invoquer est privée. Ceci nous donne donc gratuitement un filtre sur notre méthode de découverte: si la méthode est privée, on ne va pas l’invoquer. Dans nos classes Test, on pourra donc utiliser ça pour écrire des méthodes “internes” dont on pourrait avoir besoin.

InvocationTargetException arrive si une exception a lieu lors de l’exécution de la méthode. Par exemple, une AssertionError si un assert est false. On a donc notre moyen de détecter si le test a échoué.

Voyons où on en est:

public class TestRunner {
    private static String[] testClasses = {"Test.TestTest"};

    public static void main(String[] args){
        ClassLoader loader = ClassLoader.getSystemClassLoader();
        loader.setDefaultAssertionStatus(true);

        for (String c: testClasses){
            try {
                Class testClass = Class.forName(c);
                Method[] methods = testClass.getDeclaredMethods();
                for (Method m : methods) {
                    try {
                        m.invoke(null);
                    } catch (IllegalAccessException e) {
                        continue;
                    } catch (InvocationTargetException e) {
                        System.err.println("❌ Test " + m.getName() + " failed (" + e.getMessage() + ")");
                        continue;
                    }
                    System.out.println("✅ Test " + m.getName() + " passed");
                }
            } catch (ClassNotFoundException e) {
                System.err.println("Class not found: " + c);
                return;
            }
        }
    }
}

Testons:

✅ Test testSuccess passed
❌ Test testFailed failed (null)

Presque bon: le message “test has failed successfully!” n’apparaît pas. Pourquoi? InvocationTargetException ne contient pas ce message, c’est — me dit la documentation — un “wrapper” autour de l’exception dans la méthode invoquée. Je dois donc récupérer d’abord la-dite exception, qui sera normalement le AssertionError.

System.err.println("❌ Test " + m.getName() + " failed (" + e.getCause().getMessage() + ")");

✅ Test testSuccess passed
❌ Test testFailed failed (test has failed successfully!)

Cette fois, c’est bon!

Découverte automatique des classes

Java ne fournit pas de moyen simple de récupérer toutes les classes présentes dans un package, mais on peut s’en sortir grâce à notre ami le ClassLoader, celui-là même qui nous permet de voir les assert.

Un certain Victor Tatai a partagé en 2007 un bout de code permettant de faire tout ça. Créons une sous-classe privée Discovery pour encapsuler toute cette logique.