Masquage de l’information, abstraction et interfaces

Le principe : cacher ce qui est susceptible de changer

Dans la section 3.1, l’exemple KWIC de David Parnas a montré que décomposer un programme par étapes de traitement dispersait chaque décision de conception entre plusieurs modules. Son alternative, le masquage de l’information (information hiding), confie à chaque module une décision à garder secrète : comment les lignes sont stockées, comment les décalages sont calculés, à quel moment le tri a lieu. L’interface du module est choisie pour révéler le moins possible de cette décision. Tout le reste du système ne dépend que de l’interface, si bien que la décision peut changer sans que les autres parties s’en aperçoivent.

La liste de Parnas des choses qui méritent d’être cachées reste une bonne liste de contrôle un demi-siècle plus tard : les structures de données et leur mode de stockage ; l’ordre dans lequel les opérations sont effectuées ; les détails du matériel, des périphériques et des systèmes d’exploitation ; les formats d’entrée et de sortie ; et les algorithmes qui pourraient être remplacés par de meilleurs. Les ajouts modernes suivent la même logique : quel fournisseur tiers est utilisé, quelle base de données, quel courtier de messages, quelle version d’une API externe, et quelles règles métier sont en cours de révision.

Le principe s’applique de la même façon à toutes les échelles. Une classe cache ses champs ; un paquet cache ses modules internes ; un service cache sa base de données, son langage et son déploiement ; l’API publique d’une organisation cache les services qui existent derrière elle. Dans chaque cas, ce qui est caché peut changer à peu de frais, et ce qui est exposé devient coûteux à changer, parce que d’autres en dépendent.

L’encapsulation n’est pas le masquage de l’information

Les deux termes sont souvent employés comme synonymes, mais ils ne désignent pas la même chose. L’encapsulation est un mécanisme : regrouper les données avec les opérations qui les manipulent et restreindre l’accès direct, au moyen de champs privés, de frontières de modules ou de modificateurs d’accès (section 0.3). Le masquage de l’information est un principe de conception : décider quelles décisions garder secrètes, et concevoir l’interface de façon qu’elle ne les révèle pas. L’encapsulation est l’un des outils qui servent à cacher l’information ; elle ne décide pas à votre place de ce qu’il faut cacher.

Il est facile d’encapsuler parfaitement tout en ne cachant rien. Une classe dont les champs sont privés, avec un getter et un setter publics pour chacun, est entièrement encapsulée, et pourtant chaque appelant sait exactement quels champs existent et de quels types ils sont. Changez la représentation interne, et tous les appelants cassent. L’inverse se produit aussi : Python n’impose aucune confidentialité, et pourtant un module Python bien conçu peut cacher très efficacement ses décisions grâce à un ensemble de fonctions soigneusement choisi.

# Encapsulated, but the representation leaks through the interface
class Price:
    def __init__(self, pounds: float):
        self._pounds = pounds
    def get_pounds(self) -> float:          # callers now depend on 'float pounds'
        return self._pounds
    def set_pounds(self, value: float):
        self._pounds = value

# Information hiding: callers ask for what they need, not for the field
class Money:
    def __init__(self, minor_units: int, currency: str):
        self._minor, self._currency = minor_units, currency
    def add(self, other: "Money") -> "Money": ...
    def allocate(self, ratios: list[int]) -> list["Money"]: ...
    def format(self, locale: str) -> str: ...
# Switching from pence to a decimal type later changes only this class.

L’abstraction et les interfaces comme contrats

Une abstraction est une vue simplifiée de quelque chose, qui garde ce qui compte pour un objectif donné et laisse de côté le reste. Un fichier est une abstraction qui recouvre des blocs de disque, des caches et des pilotes ; un paiement est une abstraction qui recouvre un réseau de cartes, l’API d’un prestataire et le processus de règlement d’une banque. L’abstraction et le masquage de l’information sont les deux faces d’un même geste : choisir une abstraction décide de ce que montre l’interface ; cacher le reste permet de se fier à l’abstraction en toute sécurité.

Une interface est donc un contrat entre un module et ses utilisateurs. Sa partie formelle est ce qu’un vérificateur de types ou un schéma d’API peut voir : noms des opérations, types des paramètres et des valeurs de retour, types d’erreurs, noms des champs d’un corps JSON. Sa partie informelle est tout aussi contraignante : ce que fait l’opération, ses effets de bord, si elle peut être relancée sans risque, combien de temps elle prend, quelles erreurs sont possibles et ce qu’elles signifient. John Ousterhout souligne que la partie informelle ne peut être consignée que dans la documentation, et que si les utilisateurs doivent lire le code d’un module pour apprendre à s’en servir, le module ne fournit aucune véritable abstraction.

Conception par contrat

La conception par contrat, développée par Bertrand Meyer dans les années 1980 avec le langage Eiffel et décrite dans son livre Object-Oriented Software Construction et dans son article de 1992 Applying ‘Design by Contract’, rend le contrat précis. Chaque opération a une précondition, que l’appelant doit rendre vraie avant l’appel ; une postcondition, que l’opération garantit à son retour si la précondition était satisfaite ; et chaque classe ou module a des invariants, des conditions qui restent vraies entre deux opérations quelles qu’elles soient. Le contrat répartit les responsabilités : si une précondition est violée, le bug est chez l’appelant ; si une postcondition est violée, il est chez le fournisseur.

Meyer s’est opposé à l’habitude inverse, la programmation défensive, dans laquelle chaque routine vérifie tout au cas où quelqu’un l’appellerait mal. Les vérifications redondantes ajoutent du code, de la complexité et de nouveaux chemins de défaillance. Chaque condition devrait plutôt relever clairement de la responsabilité d’un seul côté. Une routine dont la précondition est exigeante est plus simple ; une routine dont la précondition est tolérante est plus facile à appeler ; ce choix est une décision de conception, prise explicitement. Aux frontières d’un système, là où les entrées viennent d’utilisateurs non fiables ou d’autres organisations, la validation n’est pas facultative : le contrat y prévoit que le module frontière vérifie lui-même tout (chapitre 8).

class Account:
    """Invariant: balance_pence >= -overdraft_limit_pence."""

    def withdraw(self, amount_pence: int) -> None:
        # Preconditions (the caller's obligations)
        if amount_pence <= 0:
            raise ValueError("amount must be positive")
        if self.balance_pence - amount_pence < -self.overdraft_limit_pence:
            raise InsufficientFunds(self.id)
        old = self.balance_pence
        self.balance_pence -= amount_pence
        # Postcondition (the supplier's guarantee)
        assert self.balance_pence == old - amount_pence
        assert self.balance_pence >= -self.overdraft_limit_pence  # invariant

Les trois mêmes idées s’appliquent aux services. Une spécification d’API, comme un document OpenAPI, énonce les préconditions (champs obligatoires, formats, authentification), les postconditions (la réponse et le changement d’état, par exemple une commande existe avec le statut PLACED) et les invariants sur lesquels un client peut compter (le total d’une commande ne change jamais après le paiement). Les tests de contrat pilotés par le consommateur, dans lesquels chaque client publie les attentes sur lesquelles il compte et le fournisseur les exécute dans son build, vérifient ces contrats automatiquement.

Les abstractions qui fuient

En novembre 2002, Joel Spolsky a publié The Law of Leaky Abstractions, qui énonce que toutes les abstractions non triviales fuient, dans une certaine mesure. Une abstraction qui fuit (leaky abstraction) est une abstraction dont les détails cachés affectent encore ses utilisateurs. TCP présente un flux fiable par-dessus un réseau non fiable, jusqu’à ce qu’un câble soit coupé et qu’il n’y parvienne plus. SQL vous permet d’énoncer ce que vous voulez, et non comment l’obtenir, jusqu’à ce que deux requêtes logiquement équivalentes diffèrent en vitesse d’un facteur mille et que vous deviez lire le plan d’exécution. Un mapping objet-relationnel (ORM) cache SQL jusqu’à ce qu’une boucle lance discrètement une requête par ligne.

La conséquence pour les architectes n’est pas que les abstractions sont mauvaises, mais qu’une interface doit être honnête sur les détails qui vont fuir. L’exemple classique est l’appel distant qui ressemble exactement à un appel de fonction local. Les appels réseau sont plus lents de plusieurs ordres de grandeur, peuvent dépasser leur délai d’expiration, peuvent réussir sur le serveur alors que la réponse se perd, et peuvent échouer indépendamment de l’appelant ; la section 6.1 les présente comme les illusions de l’informatique distribuée. Une bonne interface distante l’expose : elle prend un délai d’expiration en paramètre, renvoie des erreurs qui distinguent refusé de résultat inconnu, et accepte une clé d’idempotence pour que les nouvelles tentatives soient sans risque. Cacher complètement le réseau, c’est une fuite qui n’attend que son heure.

Modules profonds et modules superficiels

A Philosophy of Software Design de John Ousterhout (publié pour la première fois en 2018 ; deuxième édition en 2021) propose une manière utile de juger une interface. Représentez-vous chaque module comme un rectangle : le bord supérieur est son interface, que chaque utilisateur doit apprendre, et la surface est la fonctionnalité qu’il fournit. Un module profond a une petite interface au-dessus de beaucoup de fonctionnalités : il rembourse donc bien des fois le coût de son apprentissage. Un module superficiel a une interface presque aussi complexe que ce qu’il fait : il ajoute donc un coût sans cacher grand-chose.

Son exemple préféré de profondeur est l’entrée-sortie de fichiers sous Unix : une poignée d’appels (open, read, write, seek, close) cachent les systèmes de fichiers, l’organisation du disque, la mise en cache, les permissions, les périphériques et les accès concurrents. Son exemple de superficialité est une classe dont chaque méthode transmet un appel à une autre classe, ou une classe de liste chaînée dont l’interface expose presque tout ce qu’elle fait. Ousterhout soutient que le conseil courant de garder les classes et les méthodes très petites peut produire ce qu’il appelle la classite : de nombreuses classes superficielles dont les interfaces, mises bout à bout, représentent plus de complexité qu’un seul module plus profond.

Tout le monde ne suit pas Ousterhout aussi loin. Les partisans des petites classes et des petites fonctions, comme Robert C. Martin dans Clean Code, soutiennent que les unités minuscules sont plus faciles à nommer, à tester et à réutiliser ; Ousterhout et Martin ont débattu de la question dans un échange écrit publié en 2025. Les deux camps s’accordent sur l’objectif de fond, qui est de réduire la complexité qu’un lecteur doit garder en tête. À l’échelle de l’architecture, le test de profondeur est particulièrement précieux : un service dont l’API reflète ses tables de base de données une à une, avec création, lecture, mise à jour et suppression pour chacune, est superficiel, et reporte toute la vraie logique sur ses clients.

La loi de Hyrum : tout ce qui est observable devient le contrat

La loi de Hyrum, nommée d’après Hyrum Wright, alors ingénieur logiciel chez Google, par son collègue Titus Winters, et popularisée par Software Engineering at Google (2020), constate qu’avec un nombre suffisant d’utilisateurs d’une API, peu importe ce que vous promettez dans le contrat : tous les comportements observables de votre système finiront par être utilisés par quelqu’un. L’ordre dans lequel une fonction renvoie les éléments d’un ensemble non ordonné, la formulation exacte d’un message d’erreur, un champ toujours présent bien que documenté comme facultatif, le fait qu’un appel prenne 50 millisecondes : si les utilisateurs peuvent le voir, certains d’entre eux s’y fieront.

Cette loi explique pourquoi le masquage de l’information doit être conçu dès le départ, et non espéré. Chaque comportement exposé par accident fait partie du contrat de fait, et le modifier cassera quelque chose chez quelqu’un, aussi clairement que la documentation ait indiqué qu’il n’était pas spécifié. Certaines équipes rendent délibérément aléatoires les comportements non spécifiés, comme l’ordre d’itération, pour que personne ne puisse en venir à en dépendre ; Go rend aléatoire l’ordre d’itération des maps pour cette raison. D’autres gardent des réponses légères, pour qu’il y ait moins de choses dont dépendre.

Concevoir des API stables entre composants

Entre composants et services, les interfaces sont ce qu’il y a de plus coûteux à modifier, car les changer exige de se coordonner avec chaque consommateur. Les pratiques ci-dessous découlent de tout ce qui précède ; la section 0.6 a présenté les API et la section 7.7 traite en profondeur de la compatibilité des schémas.

Exemple commenté : une interface de paiement qui cache le prestataire

Une entreprise de livraison de repas encaisse ses paiements par l’intermédiaire du prestataire A. Le service financier veut ajouter le prestataire B pour réduire les frais dans un pays, et pouvoir changer de prestataire en moins d’une journée si l’un d’eux subit une panne. Aujourd’hui, le code de l’étape de paiement appelle directement le SDK du prestataire A à onze endroits, utilise ses codes d’erreur pour décider quoi afficher au client et stocke ses objets de transaction dans la table des commandes. Chacun de ces points est une décision qui a fui.

La conception introduit une interface PaymentGateway qui appartient à la boutique, et non à un prestataire. Elle s’exprime dans les termes propres à la boutique : des montants en entiers d’unités mineures avec une devise, l’identifiant de commande de la boutique, une clé d’idempotence et trois résultats possibles. Chaque prestataire reçoit un adaptateur qui implémente l’interface et traduit vers et depuis l’API, les codes d’erreur et les particularités de ce prestataire. La configuration choisit l’adaptateur selon le pays. C’est le même geste que l’intermédiaire de la section 2.6, vu cette fois comme du masquage de l’information : la décision cachée est quel prestataire, et comment l’appeler.

from typing import Protocol, Literal
from dataclasses import dataclass

@dataclass(frozen=True)
class PaymentResult:
    outcome: Literal["approved", "declined", "unknown"]  # unknown: safe to retry
    reference: str | None        # our reference, not the provider's object

class PaymentGateway(Protocol):
    def authorise(self, order_id: str, amount_minor: int, currency: str,
                  idempotency_key: str) -> PaymentResult: ...
    def capture(self, reference: str) -> PaymentResult: ...
    def refund(self, reference: str, amount_minor: int) -> PaymentResult: ...

class ProviderBAdapter:            # implements PaymentGateway
    def authorise(self, order_id, amount_minor, currency, idempotency_key):
        resp = self._client.create_charge(value=amount_minor / 100,   # B wants decimals
                                          currency=currency, key=idempotency_key)
        return PaymentResult(_map_status(resp.code), _store_ref(resp.id))

Comment les professionnels l’appliquent

Les concepteurs expérimentés partent des besoins des appelants pour concevoir une interface, en l’écrivant dans le langage de l’appelant, et ne conçoivent l’implémentation qu’ensuite. Ils tiennent la liste des décisions que cache chaque module important et examinent les nouvelles interfaces au regard de cette liste. Ils traitent chaque API publique comme un produit doté d’un cycle de vie (proposition, revue, versionnement, dépréciation) parce que, d’après la loi de Hyrum, tout ce qui est publié sera utilisé. Et ils acceptent que les abstractions fuient, si bien qu’ils rendent les fuites explicites : budgets de latence, sémantique des erreurs et règles de nouvelle tentative figurent dans le contrat.

Le masquage de l’information vous dit ce que chaque module doit garder pour lui. Il ne vous dit pas dans quel sens doivent pointer les dépendances entre modules, ni ce qui se passe quand elles forment des boucles. C’est le sujet de la section 3.4.