Couplage et cohésion

Deux mesures de la structure

Le couplage est le degré de dépendance d’un module envers un autre, tel qu’un changement de l’un peut imposer un changement de l’autre. La cohésion est le degré auquel les éléments d’un module vont ensemble parce qu’ils servent un même objectif. Ces deux idées ont été introduites par Larry Constantine à la fin des années 1960, dans le cadre du mouvement de la conception structurée, et publiées en 1974 dans l’article Structured Design de Wayne Stevens, Glenford Myers et Constantine paru dans l’IBM Systems Journal, puis plus longuement dans le livre d’Edward Yourdon et Constantine, Structured Design (1979). La section 0.3 les a présentées de manière informelle ; cette section les précise.

Les deux sont liées. Si les choses qui changent ensemble vivent dans le même module (cohésion forte), alors moins de changements traversent les frontières des modules, et les modules ont besoin d’en savoir moins les uns sur les autres (couplage faible). Yourdon et Constantine allaient jusqu’à dire qu’en pratique, la cohésion était la plus importante des deux. Les tactiques de modifiabilité de la section 2.6 (augmenter la cohésion, réduire le couplage) reposent exactement sur ce couple.

Une précision d’emblée : le couplage n’est pas un défaut. Un système dont les modules ne dépendraient jamais les uns des autres ne ferait rien d’utile. Martin Fowler, qui écrivait sur le sujet en 2001, avertissait que chercher à supprimer entièrement le couplage ne fait que tout repousser dans un seul module géant, où le couplage est caché plutôt que disparu. Le but est de choisir le couplage délibérément : peu de dépendances, passant par des interfaces étroites et stables, orientées dans des directions sensées, et aussi faibles que la tâche le permet.

Les niveaux de couplage

La conception structurée a classé les manières dont deux modules peuvent être reliés, de la plus nocive à la plus bénigne. La forme à six niveaux ci-dessous remonte généralement aux livres de Glenford Myers sur la conception composite du milieu des années 1970, et a ensuite été popularisée par Meilir Page-Jones ; les noms et les limites varient légèrement selon les sources, mais c’est la forme que l’on trouve dans la plupart des manuels. Ces niveaux ont été définis pour les procédures d’un même programme, mais chacun a un équivalent direct entre composants et entre services, et c’est là que les architectes les rencontrent aujourd’hui.

Deux mises en garde. D’abord, l’échelle est un guide du risque, pas une loi. Le couplage par estampille (stamp coupling) est souvent un compromis raisonnable : passer un objet entier est plus simple que d’en extraire six champs, et le seul coût est que le destinataire peut désormais casser quand on modifie des champs qu’il n’utilise même pas. Ensuite, l’échelle ne dit rien du nombre de dépendances ni de la fréquence à laquelle l’autre côté change. Un unique appel couplé par contrôle vers un module qui ne change jamais peut être inoffensif ; un couplage de données vers un module qui change chaque semaine peut faire mal. Plus loin dans ce chapitre, la connascence offre un vocabulaire plus fin, et Balancing Coupling in Software Design (2024), de Vlad Khononov, soutient que la force du couplage doit toujours être jugée en même temps que la distance entre les modules et leur volatilité.

# Control coupling: the caller chooses the callee's internal branch
def handle_payment(order, mode):
    if mode == "charge":
        ...  # call the provider, store the transaction
    elif mode == "refund":
        ...  # look up the transaction, reverse it
    elif mode == "dry_run":
        ...  # validate only

handle_payment(order, "refund")

# Data coupling: separate operations, each taking only what it needs
def charge(order_id: str, amount_pence: int) -> str: ...
def refund(transaction_id: str, amount_pence: int) -> None: ...

refund("tx_81f2", 1999)

Les niveaux de cohésion

La cohésion demande pourquoi les éléments d’un module sont ensemble. Yourdon et Constantine ont décrit sept sortes d’association, là encore de la pire à la meilleure. Les niveaux inférieurs regroupent des choses pour des raisons sans rapport avec le problème (elles ont été écrites au même moment, ou elles s’exécutent au même moment) ; les niveaux supérieurs regroupent des choses parce qu’elles travaillent sur les mêmes données ou vers un même objectif unique. Les synthèses ultérieures des manuels s’accordent sur le classement général : les cohésions accidentelle et logique sont médiocres, les cohésions communicationnelle et séquentielle sont bonnes et la cohésion fonctionnelle est la meilleure, même si les écarts entre niveaux ne sont pas réguliers.

À l’échelle de l’architecture, la cohésion revient à se demander si un composant ou un service a une seule raison d’exister. Un service appelé CustomerService qui gère la connexion, les points de fidélité et les préférences marketing a au mieux une cohésion logique : trois équipes le modifieront pour trois raisons sans rapport. Une bonne heuristique consiste à décrire l’objectif d’un module en une phrase sans employer et ; la section 3.5 développe cette idée sous la forme du principe de responsabilité unique, défini en fonction des personnes qui demandent les changements.

Couplage afférent et efférent

Les niveaux ci-dessus décrivent la nature d’une dépendance. Les architectes ont aussi besoin de les compter. Le couplage afférent (Ca) est le nombre de modules extérieurs à un composant qui dépendent de lui : ses flèches entrantes. Le couplage efférent (Ce) est le nombre de modules extérieurs dont il dépend : ses flèches sortantes. Ces termes viennent de l’anatomie, où les nerfs afférents transportent les signaux vers l’intérieur et les nerfs efférents vers l’extérieur. Robert C. Martin les a définis pour les paquets en 1994 en comptant des classes ; les outils actuels comptent des classes, des modules ou des paquets : vérifiez donc toujours ce que compte un outil avant de comparer des chiffres.

Les deux nombres racontent des histoires différentes. Un composant dont le Ca est élevé, comme une bibliothèque partagée money utilisée par quarante modules, est responsable : tout changement qui le touche peut en casser beaucoup d’autres, il doit donc changer avec prudence et rarement. Un composant dont le Ce est élevé, comme un flux de validation de commande qui appelle la tarification, le stock, le paiement, la livraison et les notifications, est exposé : il peut devoir changer chaque fois que l’un d’eux change. Ni l’un ni l’autre n’est un problème en soi ; le problème apparaît quand un composant est à la fois très sollicité par d’autres et lui-même dépendant de nombreux éléments volatils. La section 3.4 transforme Ca et Ce en la métrique d’instabilité de Martin et en règles fondées sur elle.

Le couplage dans les systèmes distribués

Quand les modules deviennent des services qui communiquent par un réseau, les niveaux classiques s’appliquent toujours, mais trois autres sortes de couplage prennent de l’importance. Aucune n’est visible dans la signature d’une fonction, ce qui explique pourquoi les équipes qui découpent un système en services sont souvent surprises de voir à quel point les services restent couplés.

Le couplage temporel signifie qu’une partie ne fonctionne que si une autre est disponible et réactive au même moment. Un appel HTTP synchrone de Validation vers Paiements couple leur disponibilité : si Paiements est en panne, Validation l’est aussi, et la disponibilité combinée est le produit des deux (section 2.5). Des messages asynchrones passant par une file suppriment ce couplage, au prix de résultats obtenus à terme plutôt qu’immédiatement. (En conception au niveau du code, le même terme désigne parfois le fait que des appels doivent se faire dans un ordre fixe, comme open() avant read() ; le contexte rend en général le sens évident.)

Le couplage de déploiement signifie que deux parties doivent être mises en production ensemble, ou dans un ordre fixe, parce qu’un changement dans l’une casse l’autre. Si chaque mise en production de Commandes exige une mise en production simultanée de Facturation, les deux forment en pratique une seule unité déployable, quoi qu’en dise le schéma. Les changements rétrocompatibles, les API versionnées et le patron expansion-contraction (expand and contract) sont les remèdes habituels.

Le couplage sémantique signifie que deux parties doivent s’accorder sur une signification qu’aucune interface n’exprime : qu’une commande avec status = 4 est expédiée, que les prix sont en pence et TVA comprise, qu’un « client actif » a commandé au cours des 90 derniers jours. De tels accords se rompent en silence quand l’un des côtés change son interprétation. Le remède consiste à rendre la signification explicite dans le contrat (états nommés, unités dans les noms de champs, schémas publiés) ou à garder la règle en un seul endroit que les autres interrogent.

Tactiques pour réduire le couplage

Des interfaces étroites. N’exposez que le minimum d’opérations et de champs dont les clients ont besoin. Chaque champ supplémentaire dans une réponse d’API est une chose dont un client peut finir par dépendre (voir la section 3.3 sur la loi de Hyrum). Des intermédiaires. Placez quelque chose entre les deux parties pour qu’aucune ne connaisse les détails de l’autre : un adaptateur ou une couche anticorruption qui traduit le modèle d’un fournisseur, une API gateway (passerelle d’API), ou un courtier de messages (message broker) qui découple l’émetteur du destinataire dans le temps et dans l’identité. Des événements plutôt que des commandes. Une commande (Facturation, crée une facture) oblige l’émetteur à connaître le destinataire et sa tâche ; un événement (une commande a été passée) permet à l’émetteur d’énoncer un fait et à un nombre quelconque de destinataires d’y réagir, si bien que de nouveaux consommateurs peuvent être ajoutés sans modifier le producteur. La propriété des données. Chaque donnée a un seul propriétaire qui l’écrit ; les autres modules interrogent le propriétaire par son interface ou gardent leur propre copie alimentée par des événements, sans jamais lire les tables du propriétaire (section 7.1).

Chaque tactique a un prix. Les intermédiaires ajoutent un saut et un élément de plus à exploiter. Les événements renoncent à la cohérence immédiate et rendent le déroulement d’un processus métier plus difficile à voir en un seul endroit. Les copies de données peuvent être périmées. La propriété des données oblige à construire et à versionner des API qu’une table partagée vous donnait gratuitement. Le compromis vaut la peine là où le changement est fréquent ou les équipes séparées, et souvent pas entre deux classes maintenues par une seule personne.

Exemple commenté : refactoriser un couple commandes-facturation fortement couplé

Le module Commandes d’une boutique en ligne appelle directement Facturation chaque fois qu’une commande est passée. Facturation lit ensuite la table des commandes pour en trouver les détails, interprète les codes numériques de la colonne de statut et recalcule la TVA à partir des prix des lignes. Le code ci-dessous en est une version simplifiée ; il montre trois des problèmes à la fois.

# orders.py
def place_order(basket, customer_id):
    order_id = db.insert("orders", customer_id=customer_id, status=1,
                         lines=basket.lines)
    billing.process(order_id, mode="invoice")   # Orders waits for Billing
    return order_id

# billing.py
def process(order_id, mode):
    row = db.query_one("SELECT * FROM orders WHERE id = %s", order_id)
    if row["status"] != 1:              # 1 means 'placed', by convention
        return
    net = sum(l["price"] * l["qty"] for l in row["lines"])
    vat = round(net * 0.2)               # VAT rule duplicated here
    if mode == "invoice":
        db.insert("invoices", order_id=order_id, net=net, vat=vat)
    elif mode == "credit_note":
        db.insert("credit_notes", order_id=order_id, net=-net, vat=-vat)

Toute modification de la structure de la table des commandes, des codes de statut ou des règles de TVA doit désormais être faite dans les deux modules à la fois. Commandes ne peut pas accepter une commande si Facturation est lent ou en panne. Et les deux comportements de Facturation sont choisis par un indicateur que Commandes doit connaître. La refactorisation se déroule en quatre étapes : Commandes cesse d’appeler Facturation et publie à la place un événement OrderPlaced qui transporte exactement les faits dont Facturation a besoin, y compris les totaux que Commandes a déjà calculés ; Facturation s’y abonne et enregistre les factures dans son propre stockage ; les deux comportements deviennent deux opérations ; et la table des commandes devient privée à Commandes.

# orders.py
def place_order(basket, customer_id):
    order = Order.create(customer_id, basket)      # computes net and VAT once
    repository.save(order)
    events.publish("OrderPlaced", {
        "schema_version": 1, "order_id": order.id,
        "customer_id": customer_id,
        "net_pence": order.net_pence, "vat_pence": order.vat_pence})
    return order.id

# billing.py
@events.subscribe("OrderPlaced")
def on_order_placed(event):
    create_invoice(event["order_id"], event["net_pence"], event["vat_pence"])

def create_invoice(order_id, net_pence, vat_pence): ...
def create_credit_note(order_id, net_pence, vat_pence): ...

Comment les professionnels utilisent ces idées

Les concepteurs expérimentés citent rarement le nom des niveaux lors des revues, mais ils les appliquent constamment : ils remettent en question chaque paramètre indicateur, recherchent les tables partagées et l’état global, demandent quel est l’objectif unique de chaque module, et observent dans la gestion de versions quels modules changent ensemble. Aux frontières entre équipes et entre services, ils sont stricts, car le couplage y est coûteux à défaire ; à l’intérieur d’un petit module détenu par une seule personne, ils sont plus souples, car il y coûte peu.

Ils rendent aussi le couplage visible. Un graphe de dépendances généré à partir du code, un décompte de Ca et Ce par composant et une liste des tables de base de données auxquelles accède plus d’un service font partie des vues les plus instructives d’une architecture, et tous peuvent être produits automatiquement et suivis dans le build. La section suivante aborde le principe qui maintient le couplage faible dès le départ : cacher les décisions derrière des interfaces.