Découvrez les pièges des solutions complexes
Voici un récit édifiant, celui des programmes spatiaux américains et soviétiques. Essayez de résoudre ce problème : comment écrire dans un environnement zéro gravité ? Les Américains et les Soviétiques ont chacun apporté une réponse différente.
Les ingénieurs américains ont planché sur l'élaboration d'un stylo pressurisé.
Les Soviétiques ont opté pour un crayon.
L'excès d'ingénierie est un piège dans lequel vous pourriez tomber. :D
Mais ce n'est pas le seul problème à envisager. Les systèmes logiciels gagnent en complexité au fil du temps. Les utilisateurs veulent – toujours – de nouvelles fonctionnalités, que vous devez bien sûr leur fournir. Et l’ajout de ces fonctionnalités peut, si vous n’y prenez garde, donner lieu à des conceptions inadéquates.
Voici comment surviennent les ennuis : la première fonctionnalité est facile à coder. Vous déterminez ce qu'il faut faire, effectuez le travail de conception et écrivez le code.
Vient ensuite une autre fonctionnalité qui ressemble beaucoup à la première, bien qu'elle diffère légèrement. Comment mettez-vous en place cette nouvelle fonctionnalité ? Vous avez bien entendu la solution classique du copier-coller. Prenez le code existant, faites-en un copier-coller et modifiez-le légèrement pour l'adapter à sa nouvelle destination. Répétez ensuite le processus pour les fonctionnalités suivantes. À terme, ce code devient difficile à maintenir.
Vous pouvez aussi ajouter la nouvelle fonctionnalité en rendant un peu plus complexe une classe déjà existante. Étant donné que la classe effectue déjà l'essentiel du travail, qu'entend-on par « un peu plus » ?
En réalité, le problème est double :
Tout d'abord, la solution gagne progressivement en complexité. Le nombre de personnes capables d'en comprendre le fonctionnement risque de diminuer.
Ensuite, un changement de mentalité s'opère. L'équipe commence à accepter un travail de moindre qualité, dans l'intérêt de fournir une fonctionnalité. Cela dépasse la simple conception d'une architecture médiocre, dans le sens où il devient acceptable et même inévitable de recourir à une architecture médiocre.
Lorsqu’un projet de développement gagne en complexité, que la conception définie initialement n’est, petit à petit, plus respectée, et que cela devient problématique, on parle communément de... dette technique !
Comment éviter que vos solutions deviennent difficiles à comprendre et à modifier ?
Autrement dit, comment éviter de s'endetter ? La simplicité avant tout ! Une conception simple présente plusieurs avantages. Demandez à n'importe quel mécanicien s'il préfère travailler sur un moteur de deux-chevaux ou sur celui d’un tout nouveau SUV (réponse : la première réponse). Il présente l'avantage d'être plus facile à comprendre. Et plus facile à comprendre, dit plus facile à modifier (et à réparer !). De plus, vous pouvez être davantage certain que la modification s'effectuera sans dommage.
Autre avantage, il est plus simple à tester. Si quelque chose est difficile à tester, cela signifie probablement qu'il manque de simplicité. Scinder le test et le code associé, autour de composants plus simples à tester, peut être une solution. Plus facile à dire qu'à faire.
Heureusement, vous pouvez tirer profit des connaissances de ceux qui vous ont précédé, et qui ont identifié des méthodes d'intervention efficaces.
Les principes de conception SOLID synthétisent toutes ces idées.
Identifiez les principes SOLID
Chaque lettre de l'acronyme SOLID représente un mantra à répéter pour concevoir l'architecture de votre système. Au fur et à mesure du cours, nous les analyserons chacun en détail. Nous les mettrons également en pratique en concevant une application simple de jeu de cartes.
S.O.L.I.D, qu’est-ce que ça peut bien vouloir dire ?
« S » correspond au principe single responsibility (responsabilité unique).
Une classe ne doit faire qu'une seule chose et elle doit bien la faire. Elle ne doit avoir qu'une seule raison de changer.« O » correspond au principe open/closed (ouvert/fermé).
Une classe doit être ouverte à l'extension, mais fermée à la modification.
Hmm… mais encore ?
Eh bien, lorsque vous ajoutez un nouveau concept au système (une fonctionnalité), vous ne devriez pas avoir à revenir en amont et à effectuer tout un ensemble de modifications sur l’existant pour qu’il puisse supporter le code de la nouvelle fonctionnalité.
« L » correspond au principe de substitution de Liskov.
L'ajout d'un sous-type par héritage ne doit pas rompre le code existant. C'est ce que j'appelle le principe « zéro surprise ». En d'autres termes, si le système fonctionne et que j'ajoute une nouvelle classe héritée d'une autre, le système doit continuer de fonctionner.« I » correspond au principe interface segregation (ségrégation des interfaces).
Il s'agit pour l'essentiel du principe de responsabilité unique appliqué aux interfaces.« D » correspond au principe dependency inversion (inversion des dépendances).
Les classes de haut niveau ne devraient pas avoir à être modifiées lorsqu'une classe de bas niveau est modifiée. Les classes de haut niveau doivent définir une abstraction à laquelle se conforme la classe de bas niveau.
Nous mettrons en œuvre chacun de ces principes en Java. Intéressons-nous tout d'abord à la façon dont ils sont implémentés dans une architecture connue et reconnue : l’architecture modèle-vue-contrôleur (MVC). Nous avons choisi de nous appuyer sur la structure MVC, car elle est en phase avec les principes SOLID.
En résumé
Une conception simple, réfléchie et intentionnelle amène à un code facile à comprendre, modifier et tester.
L'application des principes SOLID est une ligne directrice pour ce type de conception.
Les principes SOLID sont les suivants :
responsabilité unique ;
principe ouvert/fermé ;
substitution de Liskov ;
ségrégation des interfaces ;
inversion des dépendances.
Retrouvez-moi au chapitre suivant, où nous commencerons à combiner tout cela avec MVC !
