Le coût caché de l'indirectionThe hidden cost of indirection

Chaque abstraction ajoute un saut. La question : paie-t-elle son loyer ?Every abstraction adds a hop. The question: does it pay its rent?

Le numéro précédent disait : isole l'axe qui change. Voici le contre-poids. Une couture n'est jamais gratuite — elle ajoute un nom à apprendre, un fichier à ouvrir, un cadre de pile à traverser au débogueur, parfois un aller-retour réseau. L'indirection est l'outil principal de l'architecte… et son vice principal. Suis un simple « récupère l'email de l'utilisateur 42 » à travers ses couches.The previous issue said: isolate the axis that changes. Here's the counterweight. A seam is never free — it adds a name to learn, a file to open, a stack frame to step through in the debugger, sometimes a network round-trip. Indirection is the architect's main tool… and main vice. Follow a plain 'fetch user 42's email' down through its layers.

Le loyer se paie en lecture : huit cadres de pile pour un getter.The rent is paid in reading: eight stack frames for a getter.

L'indirection ne coûte presque rien à l'écriture — c'est ça le piège. Le coût arrive plus tard, et il tombe sur quelqu'un d'autre : celui qui débogue. Pour comprendre d'où vient un email mal formaté, il ouvre le Controller, qui renvoie au Service, qui renvoie au Manager, qui renvoie au Repository. Quatre fichiers, quatre sauts, et la seule ligne qui compte était tout en bas.Indirection costs almost nothing to write — that's the trap. The cost comes later, and it lands on someone else: whoever debugs. To understand where a malformed email comes from, they open the Controller, which points to the Service, which points to the Manager, which points to the Repository. Four files, four hops, and the only line that mattered was at the very bottom.

UserController.get_email(42)      → délègue
  UserService.get_email(42)       → délègue
    UserManager.get_email(42)     → délègue
      UserRepository.find(42)     → SQL + mapping   ← la seule ligne utile
      ↑ remonte le résultat, inchangé
    ↑ remonte le résultat, inchangé
  ↑ remonte le résultat, inchangé
↑ remonte le résultat, inchangé

Descends la pile. Pour chaque saut : décide-t-il, ou transmet-il ?Descend the stack. For each hop: does it decide, or forward?

Une seule règle de lecture : une couche vaut son saut si elle transforme, valide, décide, ou isole une frontière d'I/O. Si elle se contente de repasser l'appel, elle ajoute un cadre de pile et zéro liberté. L'animation suit l'appel vers le bas et tient deux compteurs : sauts qui paient leur loyer, et passe-plats.One reading rule: a layer earns its hop if it transforms, validates, decides, or isolates an I/O boundary. If it merely re-passes the call, it adds a stack frame and zero freedom. The animation follows the call downward and keeps two counters: hops that pay rent, and pass-throughs.

Une frontière qui transforme, ou une couche qui redélègue.A boundary that transforms, or a layer that re-delegates.

Les deux extraits ajoutent de l'indirection. Mais l'un achète une liberté — le métier ne dépend plus du schéma SQL, il dépend d'un email validé — et l'autre n'achète rien : trois méthodes qui repassent l'argument tel quel. Bascule le toggle. La question n'est pas « combien de couches ? » mais « que décide chacune ? ».Both snippets add indirection. But one buys a freedom — the business no longer depends on the SQL schema, it depends on a validated email — and the other buys nothing: three methods re-passing the argument unchanged. Flip the toggle. The question isn't 'how many layers?' but 'what does each decide?'.

# une seule couture, et elle DÉCIDE
class UserRepository:
    def find_email(self, id) -> str:
        row = db.query("SELECT email FROM users WHERE id=?", id)
        if row is None:
            raise UserNotFound(id)          # ① une décision
        return row.email.lower().strip()    # ② une transformation
# le reste du code dépend d'un email validé, pas de SQL