Pourquoi les principes SOLID ?
En général, on se dit que les règles et principes visant à introduire des améliorations dans un domaine se développent peu à peu au fil des années, avec l'apport de nombreux acteurs. Et pourtant, ce n'est qu'en 2000 que les principes SOLID ont vu le jour ! Ils constituent un sous-ensemble des nombreux principes énoncés par Robert C. Martin, dit "Uncle Bob", un ingénieur logiciel et formateur américain.
Bien souvent, les développeurs foncent dans leur projet tête baissée, sans trop réfléchir à son architecture globale ou à sa capacité à évoluer. Ce type de code finit par devenir fragile et rigide, car il contient des défauts que l'on appelle des "code smells" (mauvaises odeurs).
En raison de ces défauts, le moindre changement peut, par effet domino, produire des bugs dans d'autres parties du logiciel. Par ailleurs, l'ajout d'une nouvelle fonctionnalité risque d'imposer la réécriture de vastes pans du code et là encore de générer de nombreux bugs.
Pour éviter ces erreurs, vous devez toujours suivre les principes SOLID. Cet acronyme regroupe 5 principes de la programmation orientée objet qui facilitent le développement de logiciels plus faciles à maintenir et à enrichir.
SOLID signifie :
Single responsibility (Responsabilité unique) ;
Open/closed (Ouvert/fermé) ;
Liskov substitution (Substitution de Liskov) ;
Interface segregation (Ségrégation des interfaces) ;
Dependency inversion (Inversion des dépendances).
Dans la deuxième partie de ce cours, nous allons nous attarder sur chacun des principes. Nous verrons quand il convient de les appliquer et nous les illustrerons avec des exemples.
Nous renforcerons également vos compétences en conception en apprenant les principes à ne pas suivre : les principes STUPID.
Principes STUPID
Nous avons vu un peu plus haut que lorsque les développeurs ne suivent pas les principes SOLID, ils produisent un code de mauvaise qualité. Pas de panique pour autant ! Je peux vous assurer que tous les développeurs, moi le premier, ont déjà écrit du code STUPID.
Mais alors, en quoi consistent ces nouveaux principes ?
L'acronyme STUPID signifie :
Singleton (Utilisation de singletons)
Tight coupling (Couplage fort)
Untestability (Impossible à tester)
Premature optimization (Optimisation prématurée)
Indescriptive naming (Nommage non descriptif)
Duplication
J'expliquerai chacun de ces principes en détail à la fin de la deuxième partie du cours et nous verrons comment les éviter.
Si je tiens à vous les présenter, c'est pour que vous soyez plus vigilant quand ils apparaissent dans votre code et, ainsi, mieux préparé à les éviter.
Après avoir compris à la fois les principes SOLID et les principes STUPID, vous aurez toutes les cartes en main pour concevoir des logiciels dans les règles de l'art.
En résumé
Un code propre est plus facile à comprendre, à maintenir, à modifier et à tester.
L'application des principes SOLID permet d'écrire du code plus propre. Ces principes sont :
Single responsibility (Responsabilité unique)
Open/closed (Ouvert/fermé)
Liskov substitutability (Substitution de Liskov)
Interface segregation (Ségrégation des interfaces)
Dependency inversion (Inversion des dépendances)
À l'inverse, les principes STUPID sont source de problèmes. Il s'agit de :
Singleton (Utilisation de singletons)
Tight coupling (Couplage fort)
Untestability (Impossible à tester)
Premature optimization (Optimisation prématurée)
Indescriptive naming (Nommage non descriptif)
Duplication
Maintenant que nous avons vu les notions de base sur ce qu'est un code de qualité, passons au chapitre suivant. Nous allons découvrir l'architecture MVC !
