OTAKU est un acronyme, et chaque lettre est une contrainte. Quarante règles le rendent mesurable ; une métrique décide si une méthode est trop complexe pour exister.
La philosophie a un noyau rigide et des bords souples. Le noyau — les cinq piliers et les seuils qui les rendent opérationnels — ne négocie pas. Les bords — langage, framework, style, outillage — sont libres.
L’ordre des cinq piliers est intentionnel. La discipline vient d’abord parce que rien ne survit sans elle. Les contrats viennent en dernier parce qu’ils sont la seule chose que le monde extérieur a le droit de voir.
Maîtrise ta Discipline
Sois strict avec toi-même.
La restriction est le seul chemin vers la liberté. Complexité, taille et nommage se mesurent, ils ne se débattent pas.
Outils de Composition
Compose comme Unix.
Des pièces petites aux entrées et sorties claires. L’application est un tuyau de données et les effets restent aux bords.
Blindez le Cœur
Protège le cœur du métier.
Les dépendances pointent uniquement vers l’intérieur. Entités et cas d’usage ignorent le nom d’un framework.
Gardez l’Infrastructure Silencieuse
L’infrastructure n’est qu’un détail.
La persistance se comporte comme une collection en mémoire. L’échec est explicite ; l’état est immuable par défaut.
Langage Universel et Contrats
Parle la langue de l’utilisateur.
Langage ubiquitaire explicite dans des contrats design-first. Les primitifs sont encapsulés ; chaque méthode publique a un contrat.
La métrique principale
La complexité cyclomatique — le nombre de chemins indépendants d’une méthode, selon Thomas J. McCabe — est l’instrument principal de la philosophie. Une méthode au-delà de 5 est rejetée, aussi lisible paraisse-t-elle. Cinq chemins sont déjà cinq raisonnements que le lecteur doit tenir simultanément.
Tout le reste de la section discipline sert à garder ce nombre bas : un seul niveau d’indentation, pas de ELSE, pas de switch/case, des clauses de garde, de l’extraction. La métrique est mesurable dans tous les langages de ce livre, et chaque écosystème a un outil qui la rapporte.
Les quarante règles
Chaque règle a un seuil mesurable. En cas de doute, choisissez l’option la plus restrictive.
40 règles · 7 groupes · 5 piliers
OComplexité
- La complexité cyclomatique par méthode ne doit pas dépasser 5.
- Un seul niveau d’indentation par méthode.
- Ne pas utiliser le mot-clé ELSE (clauses de garde ou retours anticipés).
- Ne jamais utiliser switch/case (polymorphisme, expressions match ou stratégie).
- Éviter les nombres et chaînes magiques (constantes ou énumérations).
OTaille
- Maximum de 50 lignes par classe (uniquement le code du corps de la classe).
- Maximum de 20 lignes par méthode (code exécutable uniquement).
- Maximum de 10 classes par namespace ou paquet.
- Aucune classe avec plus de deux variables d’instance.
- Les méthodes ne doivent pas avoir plus de deux paramètres.
- Les constructeurs ne doivent pas avoir plus de deux paramètres.
- Les interfaces ne doivent pas avoir plus de deux méthodes.
ONommage
- Ne pas abréger ; utiliser des noms complets et descriptifs.
- Les méthodes booléennes commencent par is, has, can ou should.
- Les noms de méthodes commencent par un verbe.
- Les constantes sont en UPPER_SNAKE_CASE.
- Les propriétés et méthodes sont en camelCase.
TModularité
- Collections de première classe : encapsuler les tableaux dans des classes dédiées.
- Un point par ligne ; éviter le chaînage de méthodes.
- Les méthodes statiques sont interdites, sauf fabriques et fonctions pures.
- Commandes et requêtes séparées : pas d’effet de bord dans une méthode qui retourne une valeur.
- Fonctions pures quand c’est possible : même entrée, même sortie, aucun effet de bord.
- Pas d’état global ni de singletons ; injecter les dépendances explicitement.
- Préférer des fonctions petites et ciblées ; extraire dès qu’une méthode fait plus d’une chose.
AProtection
- Pas de getters, setters ni propriétés publiques ; utiliser des méthodes de comportement.
- Propriétés privées par défaut ; protected uniquement pour l’héritage de framework.
- Classes finales par défaut ; l’extension passe par les interfaces.
- Héritage interdit sauf classes de base de framework ; préférer la composition.
- Valider toutes les entrées à la frontière : constructeurs et méthodes publiques.
- Échouer vite : lever dès qu’une précondition est violée.
- Ne jamais muter les paramètres d’entrée ; les traiter comme immuables.
KEffets de bord et échec
- Préférer l’immuabilité : propriétés readonly, retourner de nouvelles instances.
- Les méthodes qui retournent des collections retournent une collection vide, jamais null.
- Les méthodes qui peuvent échouer retournent Result/Either ou lèvent une exception ; jamais null.
- Explicite plutôt qu’implicite : pas de dépendances cachées, méthodes magiques ni conversions implicites.
- Ne jamais laisser fuiter des détails d’infrastructure (SQL, HTTP, chemins de fichiers) dans le domaine.
UContrats
- Encapsuler tous les primitifs et chaînes dans des objets de valeur.
- Pas de types génériques (mixed, array, object) sauf méthodes explicites de sérialisation.
- Chaque méthode publique est déclarée dans une interface.
- Les commentaires expliquent le pourquoi et appartiennent aux contrats, pas aux implémentations.
Comment les piliers se soutiennent
La discipline rend la composition possible : une classe de 300 lignes ne se remplace pas. La composition rend le cœur défendable : un monolithe ne peut pas cacher ses dépendances. Un cœur protégé rend l’infrastructure réellement optionnelle. Les contrats sont la seule raison pour laquelle tout cela se vérifie de l’extérieur.
Retirez un pilier et les autres deviennent une cérémonie. Gardez les cinq et le système devient ennuyeux — de la même façon qu’un pont est ennuyeux.