Réponse.

La décomposition est le fait de diviser une grande tâche en sous-tâches ou fonctions plus simples et gérables. Historiquement, la décomposition est née comme un principe clé de programmation modulaire : elle simplifie la gestion de la complexité, la testabilité et la réutilisation du code.

Problème : Sans décomposition, le code devient un "monolithe" : il est difficile à lire, à maintenir et à modifier, plus compliqué de rédiger des tests et de réutiliser des parties du programme.

Solution : En Python, la décomposition est mise en œuvre en divisant la logique en fonctions, classes et modules ; en nommant clairement ; en utilisant la composition et les abstractions. Cela permet d'écrire un code lisible et extensible.

Exemple de code :

# Code monolithique non compact
numbers = [1, 2, 3, 4]
squares = []
for n in numbers:
    if n % 2 == 0:
        squares.append(n**2)
print(squares)

# Version décomposée

def is_even(n):
    return n % 2 == 0

def square(n):
    return n ** 2

def filter_and_apply(numbers, predicate, func):
    return [func(n) for n in numbers if predicate(n)]

numbers = [1, 2, 3, 4]
result = filter_and_apply(numbers, is_even, square)
print(result)

Caractéristiques clés :

Améliore la lisibilité et la maintenance du code
Simplifie le test et le débogage
Augmente la réutilisabilité des composants

Questions pièges.

Une fonction peut-elle réaliser toute la logique métier si elle est petite ?

On pense souvent que si une tâche est petite, il est permis d'écrire "une fonction de 100 lignes". C'est un anti-modèle : même une petite tâche devient compliquée avec le moindre changement ; les micro-fonctions sont beaucoup plus faciles à tester et à maintenir.

Les fonctions avec une logique identique mais des noms différents peuvent-elles être considérées comme une décomposition ?

Non, la duplication de code est une mauvaise décomposition. Le code répété indique que les limites des sous-tâches ont été mal choisies. Il faut toujours extraire les fonctionnalités répétées dans des fonctions auxiliaires.

Exemple :

def add_user():
    pass  # logique

def add_admin():
    pass  # même logique que ci-dessus !

Faut-il décomposer les tâches auxiliaires si elles ne sont utilisées qu'à un seul endroit ?

Oui, souvent ces fonctions aident à simplifier le code même en cas d'utilisation unique (par exemple, extraire des conditions ou des filtrages dans une fonction séparée).

Erreurs typiques et anti-modèles

Fonctions longues et monolithiques sans divisions claires en étapes de travail
Duplication de code, au lieu de solutions universelles
Décomposition "trop fine" : fonctions d'une ligne qui n'ont pas de charge sémantique

Exemple de la vie réelle

Cas négatif

Un projet de traitement de données passait par une énorme fonction de 300 lignes. Chaque bug provoquait la panique : il était impossible de comprendre rapidement ce qui s'était passé, les tests étaient pratiquement impossibles.

Avantages :

Le code est en un seul endroit

Inconvénients :

Difficulté de lecture, impossible de tester les morceaux séparément
Coûts de maintenance élevés

Cas positif

Le même projet, refonte — le code a été divisé en petites fonctions et classes selon la logique principale (lecture, validation, traitement, écriture des données).