Modularité et API : cours de Terminale NSI

Quand tu écris un petit script de vingt lignes, tout tient dans ta tête. Quand un projet grossit, ce n'est plus possible : plusieurs personnes y travaillent, le code est relu des mois plus tard, une même fonctionnalité sert à plusieurs endroits. Il faut alors séparer proprement les différentes parties du projet.³

Tu as déjà utilisé cette idée en classe de première : tu as écrit des fonctions, importé des bibliothèques comme math ou random. La modularité est une méthode essentielle de programmation, que l'on reprend ici de façon plus approfondie.² Ce cours explique ce que cela signifie concrètement, comment on le met en œuvre en Python et comment on décrit ce qu'une partie du programme offre aux autres.

Voici ce que le découpage apporte, raisonnement à l'appui :

• Lisibilité : chaque partie a un rôle précis, que l'on résume en une phrase.³
• Réutilisation : une fonction bien isolée sert dans plusieurs programmes sans être recopiée.
• Travail à plusieurs : deux élèves peuvent écrire deux parties en parallèle, à condition de s'être mis d'accord sur ce que chaque partie offre.³
• Maintenance : si un bogue apparaît, on sait dans quelle partie le chercher.
• Tests : on vérifie chaque partie seule, avant de les assembler.

Prenons un fichier geometrie.py :

PI_APPROCHE = 3.14

def aire_disque(r):
    return PI_APPROCHE * r * r

def aire_rectangle(longueur, largeur):
    return longueur * largeur

Un second fichier, main.py, placé dans le même dossier, peut s'en servir :

import geometrie

print(geometrie.aire_rectangle(4, 3))
print(geometrie.aire_disque(2))

Le préfixe geometrie. indique d'où vient la fonction. On évite ainsi de confondre deux fonctions de même nom venant de modules différents.

On peut comparer un module à un distributeur de boissons. Tu vois les boutons, la fente de paiement et le bac de sortie : c'est l'interface. Tu ignores comment fonctionne le mécanisme intérieur, et tu n'as pas besoin de le savoir. Si le fabricant change le mécanisme en gardant les mêmes boutons, tu continues à utiliser la machine comme avant.

En programmation, c'est exactement le but : celui qui utilise le module ne dépend que de l'API, jamais de la façon dont elle est réalisée.

Mettons tout cela en pratique avec une structure que tu connais : la pile, où l'on empile et dépile des éléments, le dernier arrivé étant le premier sorti. Plaçons-la dans un module pile.py. Pour concevoir une API, on commence par se demander : de quoi un utilisateur a-t-il besoin ? On répond par une liste courte d'opérations.²

Ce programme n'utilise que les cinq fonctions de l'API. Il ne manipule jamais directement la liste p avec p.append ou p[0]. C'est ce qui permet de réécrire le module autrement.

Le même module peut s'écrire avec une classe. Les données internes sont alors rangées dans l'objet, et les méthodes jouent le rôle des fonctions de l'API.

class Pile:
    def __init__(self):
        self._elements = []

    def est_vide(self):
        return len(self._elements) == 0

    def empiler(self, x):
        self._elements.append(x)

    def depiler(self):
        assert not self.est_vide()
        return self._elements.pop()

    def taille(self):
        return len(self._elements)

L'utilisateur écrit p = Pile(), puis p.empiler(3). Le nom _elements commence par un tiret bas : il appartient à l'intérieur de la classe, l'API se limite aux méthodes.

Une API n'a de valeur que si elle est comprise et fiable. Deux outils y contribuent : la documentation et les tests.