Dans ce billet, je souhaite vous introduire une série d’articles sur la conception objet. Ces articles peuvent s’adapter à d’autres langages que C#, ils pourront donc aussi intéresser les développeurs utilisant d’autres langages.
Les principes de conception objet, très souvent, sont des notions vues à l’école pendant vos études. Les profs vous ont expliqué les notions de polymorphisme, d’héritage, d’encapsulation dans les grandes lignes.
Aujourd’hui, je ne vais pas vous assommer avec ces notions mais je souhaite parler de principes qui me semblent fondamentaux au quotidien pour un bon développeur, surtout pour des projets d’entreprises qui doivent vivre dans le temps.
L’utilisation de ces différents principes permettra d’obtenir des applications :
- plus faciles à faire évoluer
- plus faciles à maintenir
- plus robustes
Vous vous demandez sûrement pourquoi je lance cette série d’articles théoriques. Et bien la réponse est très simple.
Je rencontre régulièrement des développeurs qui ne connaissent pas ces théories et qui « codent » donc un peu en suivant leur instinct. Cela peut marcher après quelques années d’expérience et d’apprentissage « sur le tas » mais l’instinct ne fonctionne pas quand vous débutez.
La conséquence de leur manque de connaissance en conception objet est, très souvent, la mise en place d’une application mal conçue.
Pour de petits projets, ça passe dans la plupart des cas. Mais les projets grandissent et évoluent. Au final, le développeur met de plus en plus de temps pour faire une petite évolution sur l’application. Bref, les délais explosent.
Résultat : vous passez de plus en plus de temps à chercher comment modifier l’application et vous vous dites : « mince, si j’avais mieux conçue cette partie, je pourrais la faire évoluer plus facilement aujourd’hui ».
Rassurez-vous, tout le monde est passé par là (et moi aussi) car même les bons développeurs font parfois de mauvais choix de conception. Personne n’est parfait ! Heureusement pour nous, il existe des principes à respecter que l’on peut mettre en place très facilement.
Respecter ces principes permet de garantir une bonne architecture et de faciliter la maintenabilité.
La procédure
Cet article serait trop long si je vous détaillais l’ensemble des concepts dans un seul billet. Je vous propose donc de découvrir dans les prochains jours des articles qui continuent cette série.
Au menu, voici ce que je vous propose :
- SRP (Single Responsibility Principle)
- OCP (Open Closed Principle)
- LSP (Liskov Substitution Principle)
- ISP (Interface Seggregation Principle)
- DIP (Dependancy Inversion Principle)
L’ensemble de ces principes sont regroupées sous la forme d’un acronyme : SOLID.
Je tiens à préciser également que je ne suis pas l’inventeur de ces principes. Ils ont été crées et imaginés par Robert C. Martin dans les années 2000.
Pour chaque article, je vous explique le principe à connaitre, je vous montre comment l’appliquer avec un exemple concret.
Pour démarrer tout de suite, je vous invite à découvrir le premier article de cette série : des applications SOLID avec SRP (2/6).