[DUMD 14/24] C'est quoi les principes SOLID ?

Auteur du billet de blog : Nicolas Hilaire - Neotech Solutions

Nicolas Hilaire

Consultant .NET
  Publié le mercredi 4 janvier 2017

Artisan logiciel particulièrement intéressé par les technologies .NET. Polyvalent et curieux, je suis néanmoins à l'écoute des autres technologies du marché. MVP (Microsoft Most Valuable Professional) de 2007 à 2014, je suis également auteur d'un ouvrage pour apprendre le C#, à destination des débutants et de plusieurs MOOCs sur le C#, Windows Phone ou ASP.NET MVC...

Quatorzième billet sur comment devenir un meilleur développeur. Pour retrouver le sommaire ainsi que tous les liens, rendez-vous sur le premier billet.

 

Nous allons parler dans les 5 billets à venir des principes SOLID. Encore un acronyme sympathique pour retenir plus facilement des principes et des bonnes pratiques. SOLID, ce sont des conseils vous permettant de mieux réussir vos conceptions orientées objets. Nous avons déjà vu quelques-uns de ces principes, comme le fait de programmer une abstraction et non une implémentation. Ou de préférer la composition à l'héritage.

Le but est toujours de faire en sorte que votre code soit le plus simple possible, de gérer vos dépendances correctement et de faire en sorte que votre code soit moins rigide, moins fragile et plus extensible.

Pour simplifier, on pourrait dire que ces principes vous aident à assurer des développements de qualité en suivant des méthodes agiles. Ces dernières ayant tendance à privilégier des conceptions simples et des itérations courtes, il faut donc les coupler avec des bonnes pratiques de développement.

 

S.O.L.I.D

Derrière cet acronyme se cachent les principes suivants, que je détaillerai dans un billet dédié à chacun :

 

Initiale Principe Abréviation
S

Single responsibility principle (Responsabilité unique)

Une classe doit avoir une et une seule responsabilité

SRP
O

Open/closed principle (Ouvert/fermé)

Une classe doit être ouverte à l'extension, mais fermée à la modification

OCP
L

Liskov substitution principle (Substitution de Liskov)

Une instance d'un objet doit pouvoir être remplacée par un sous-type sans modifier la cohérence du programme

LSP
I

Interface segregation principle (Ségrégation des interfaces)

Préférer plusieurs interfaces spécifiques pour chaque client plutôt qu'une seule interface générale

ISP
D

Dependency inversion principle (Inversion des dépendances)

il faut dépendre des abstractions, pas des implémentations

DIP

 

A l'origine, ces principes n'étaient pas ordonnés de cette façon et l'acronyme SOLID a été proposé plus tard comme moyen mémo-technique. Et puis, ça en jette comme acronyme ; c'est classe de dire que son code est SOLID(e) ! :).

Du coup, je vais les traiter dans un autre ordre que celui de l'acronyme car il me parait primordial de présenter au plus tôt le principe d'inversion de dépendances. Nous avons déjà parlé d'abstractions et d'implémentations, mais ici nous allons aller encore plus loin.

N'oubliez pas, comme nous l'enseignent les méthodes agiles, de toujours commencer à faire simple. C'est seulement quand le changement arrive qu'il est bon de se rappeler ces principes. En effet, vous ne saurez jamais à l'avance où le changement va arriver. Le client ne le sait pas non plus d'ailleurs. Tout ce qu'on sait c'est que ça va changer, donc le plus sage est d'attendre le changement avant de mettre en place des abstractions.

 

Conclusion

Nous n'avons pas détaillé grand chose dans ce billet, il s'agissait juste d'introduire les principes et vous donner envie d'aller plus loin. Je voulais aussi vous rappeler qu'il ne s'agit que de principes, et pas fatalement d'une loi absolue et intransigeante. N'oubliez pas qu'il peut toujours y avoir des exceptions, et vous vous devez de réfléchir avant d'appliquer à la lettre ces principes.

Si vous ne devez retenir qu'une chose de ces principes, ça serait de :

 

Faire en sorte que les choses qui bougent beaucoup dépendent des choses qui ne bougent pas.

 

 Dans le prochain billet, nous allons disséquer le principe d'inversion des dépendances.

Commentaires