Alheim

Il y a plus d’un an (le temps passe vite), j’avais eu l’idée d’écrire une série de billet sur les design smells.

Petit rappel : qu’est ce qu’un design smell ?

Il s’agit d’une portion de code dont la complexité peut entraîner :

• des difficultés à le maintenir
• des dépendances fortes entre composants qui rendent ce code impossible à tester unitairement
• un passage forcé par du refactoring pour la moindre évolution

J’avais évoqué le cas du code dupliqué (duplicated code), et des méthodes de classe trop longue (long method).

Ce billet traite d’un design smell commun dans le développement web : God Object (pas de blague vaseuse s’il vous plaît).

De quoi s’agit il ?

Dans la programmation objet, un God object est un objet qui en sait trop ou qui en fait trop.

Pourquoi est ce un design smell ?

Une des idées principales derrière la programmation objet, et structurée en générale, est qu’un problème peut être découpé en sous-problèmes et que des solutions apportées à chacun de ces sous-problèmes permettent de résoudre le problème initial. Vous suivez toujours ?

Prenons l’exemple de la programmation MVC. Les contrôleurs sont des classes utilisées pour exécuter le code applicatif entre la réception de la requête http, et le rendu dans le navigateur. Le champs d’action est vaste. Certes la couche modèle permet de déporter du code, lié à la base de données, mais trop souvent, les contrôleur font beaucoup trop de choses.
Conséquences : le code devient difficilement maintenable, et encore moins testable unitairement car trop de comportements doivent être pris en compte.

Imaginons une application qui authentifie un utilisateur, lui demande de saisir un texte, vérifie le texte et l’envoi par email. Le premier design qui vient à l’esprit est une classe contrôleur appelée à la soumission du formulaire, et une classe dans le modèle DAO ou ORM qui stocke le message dans la base de données.
Quels sont alors les comportements associés au contrôleur ?

• authentification
• validation du texte
• appel au DAO
• envoi du mail

C’est l’exemple d’un God Object. Comment tester la validation du texte sans avoir authentifié un utilisateur ? Comment tester l’envoi du mail sans valider le texte ? etc…

Développer une classe qui accomplit toutes ces tâches revient à faire de la programmation procédurale… à l’intérieur d’une classe.

Voila donc comment on peut se retrouver à avoir des classes de plusieurs milliers de lignes pour gérer une ou plusieurs actions d’une application WEB.

Quelle solution ?

…car il y en a une. L’idée est de différentier les comportements orthogonaux (authentification, email, validation de texte) et de les écrire dans des composants dédiés. Ainsi la classe de gestion d’authentification ne verra rien d’autre qu’un identifiant et un mot de passe, la classe de gestion de mail, un texte et une adresse de destination etc….
Tout devient plus simple à maintenir et à tester.

En conclusion, l’étude de se design-smell permet de toucher du doigt un problème majeur de la programmation web MVC. S’il est possible de tester unitairement des objets de connexion à une base de données, ou une classe de filtrage de texte, il est très difficile de tester les contrôleurs car ils sont liés à la requête http, inexistante dans un contexte de tests unitaires. En utilisant des classes spécialisées, le code est mieux testé, plus robuste et plus évolutif.