mardi 9 juillet 2013

De la solidité que diable ! (SOLID 1/5)

Ce post fait partie de la série S.O.L.I.D.

Aujourd'hui un poste purement informatique, qui te fera passer Kant pour de la lecture de 6e.

Ces dernières années, le développement informatique est devenu plus abouti, plus mature, plus solide, plus SOLID. SOLID, comme le mot convient bien, autant en français qu'en anglais, ça tombe bien. Donc oui, fini les constructions logiciels qui s’effondrent dés qu'on pose un pied dessus. Un ensemble de règles a vu le jour pour faire des constructions logiciels fiables et robustes. Ça a l'air compliqué au départ, mais c'est pas si sorcier, même toi tu vas y arriver.

SOLID est un acronyme de cinq lettres, chacune définissant un principe. Attention c'est hard :
SOLID, le développement logiciel n'est pas une jeu de Jenga

Donnez moi un S (comme single), le principe de responsabilité unique.

Le principe veut que chaque classe, chaque objet, ne serve qu'à un unique but. Fini les classes qui font des centaines et des centaines de lignes. Quand tu crées ta classe, pose toi la question : à quoi va-t-elle servir. Tu dois avoir une et une seule notion en tête. Je veux modéliser un canard. Je crée la classe Canard. A quoi va-t-elle servir ? A modéliser Canard.

Je vais créer la classe ExcelIO. A quoi va-t-elle servir ? A extraire un fichier excel pour les rapports annuels, et à lire les fichiers d'imports des commerciaux. BIIIIIP, FAUX, ERREUR. Deux notions, deux classes. Demain le rapport annuel changera, pas le fichier d'import. La classe qui sert à lire les fichiers d'import va être modifiée sans raison valable, et c'est une erreur.

On arrive à la notion sœur : un objet doit avoir une et une seule raison de changer.

Ce n'est pas parce que tu peux le faire que tu dois le faire
Les raisons de ce principe, c'est d'éviter les effets de bords. Quand le client viendra t’engueuler parce que ses imports ne fonctionnent plu, alors que seule la fonction du rapport annuel devait changer, tu comprendras ta douleur.
Toucher du code, c'est dangereux, et invariablement, ça crée des bugs, donc autant toucher le moins de code possible lors d'un changement.

L'autre utilité de ce principe, c'est d'avoir des classes plus courtes, plus restreintes, avec moins de code. Donc plus compréhensible par tes collègues, et par le toi du futur.

Fini les classes couteaux suisses, qui démarrent le moteur, remplissent la piscine et font le café.
On les connait bien, ces classes qui accèdent à l'interface utilisateur, parsent les données d'entrée, interrogent la base de données, interprètent les résultats, sortent des rapport avec agrégations des résultats. NON, STOP. Ton fichier .php qui fait tout en même temps, c'est fini.

On parle aussi de `god-like object`, des objets dieux, omniscient qui connaissent tout sur tout. On les appelle souvent Manager. ExcelManager, FormManager, etc... C'est un `code-smell`, en gros, quand tu vois une classe qui s'appelle machinChoseManager, ou quand tu t’apprêtes à la créer, STOP, ça pue. Lève les mains de ton clavier, et réfléchis.

On découpe on découpe on découpe. Chacun ses responsabilités, tu verras, tu me remercieras dans 6 mois.