Design Principles & Component Principles

Introduction

Aujourd’hui, je vais vous parler de ce qui est réellement important en programmation.
J’ai souvent entendu dire que certains langages ou frameworks sont plus importants que d’autres, ce qui, selon moi, est complètement faux.

Je ne suis pas un expert en programmation, mais j’ai découvert que les éléments les plus importants sont le code propre, la structure et la manière dont le logiciel est construit.

J’ai donc décidé d’écrire cet article pour vous donner quelques informations sur les principes qui vous aideront à construire des logiciels solides. Bien sûr, je vous encourage à faire vos propres recherches et à approfondir chaque sujet.

Il existe deux grands ensembles de principes :
👉 Les principes de conception (Design Principles)
👉 Les principes de composition des composants (Component Principles)

Ces deux ensembles se complètent :

• Les Design Principles servent à créer des composants solides.

• Les Component Principles servent à organiser ces composants dans des systèmes complexes.

Dans cet article, je vais donner une définition de chacun, et je détaillerai leur contenu avec des exemples dans d’autres articles, pour éviter toute confusion.

1 – Les principes de conception (Design Principles)

🔹 Les principes SOLID

Tout d’abord, les principes de conception — ou principes SOLID — ont été définis par Oncle Bob (Robert C. Martin) en 2004.

Le but de ces principes est d’organiser les éléments d’un logiciel en composants afin de les rendre :

• Faciles à comprendre

• Faciles à réutiliser dans d’autres systèmes

• Faciles à modifier

Les principes SOLID comprennent cinq règles essentielles :

SRP : Single Responsibility Principle (Principe de responsabilité unique)
C’est un principe simple à comprendre : chaque module, classe ou fonction doit faire une seule et unique chose.

OCP : Open/Closed Principle (Principe Ouvert/Fermé)
Comme l’a dit Bertrand Meyer : Un artefact logiciel doit être ouvert à l’extension, mais fermé à la modification.
L’objectif est d’éviter de modifier le code existant lorsqu’on ajoute de nouvelles fonctionnalités.

LSP : Liskov Substitution Principle (Principe de substitution de Liskov)
Ce principe souligne l’importance de la substitution par sous-type.
Il signifie que les objets d’une superclasse doivent pouvoir être remplacés par des objets de leurs sous-classes sans casser le fonctionnement du programme.

ISP : Interface Segregation Principle (Principe de ségrégation des interfaces)
Ce principe recommande d’éviter de dépendre de choses que l’on n’utilise pas.
Autrement dit, il vaut mieux avoir plusieurs petites interfaces spécifiques plutôt qu’une grande interface générale.

DIP : Dependency Inversion Principle (Principe d’inversion des dépendances)
C’est pour moi le plus important, car il est au cœur de l’architecture propre (Clean Architecture) et traverse toutes les couches du système.
Il signifie que le code de haut niveau (logique métier, domaine) ne doit pas dépendre du code de bas niveau (framework, base de données, interface graphique), mais que les deux doivent dépendre d’abstractions.

Je rédigerai un article détaillé pour chacun de ces principes avec des exemples concrets pour une meilleure compréhension.

2 – Les principes des composants (Component Principles)

Lorsque nous travaillons sur de grands systèmes, il faut penser à ces principes, car tout grand système est constitué de petits composants.
Nous avons donc besoin de règles pour organiser ces composants afin de rendre notre système plus solide.

Ces principes décrivent comment les composants doivent être composés.
Un aspect essentiel ici est la cohésion des composants :
elle nous indique quelles classes doivent appartenir à quel composant.
C’est souvent une décision difficile qui nécessite une bonne compréhension de l’architecture logicielle.

Ce sujet comprend trois principes principaux :

REP : Reuse/Release Equivalence Principle (Principe d’équivalence réutilisation/publication)
Celui-ci peut sembler un peu abstrait. Il dit simplement que pour qu’un composant soit réutilisable, il doit être publié et avoir un numéro de version (release).

CCP : Common Closure Principle (Principe de fermeture commune)
De la même manière que le SRP stipule qu’une classe ne doit avoir qu’une seule raison de changer,
le CCP stipule que les composants ne doivent pas avoir plusieurs raisons de changer.

CRP : Common Reuse Principle (Principe de réutilisation commune)
Ce principe aide à décider quelles classes ou modules doivent être regroupés dans un même composant.
Mais il indique aussi quelles classes ne devraient pas être regroupées ensemble.
C’est la version « composant » du principe ISP : il conseille de ne pas dépendre de composants contenant des éléments que nous n’utilisons pas.

Conclusion

Dans cet article, j’ai défini les éléments les plus importants en programmation : les principes de conception (Design Principles) et les principes des composants (Component Principles).
Ces concepts sont essentiels pour construire des systèmes logiciels robustes et évolutifs.

Cet article n’est qu’une introduction. Dans les prochains, je détaillerai chacun des principes, avec des exemples d’implémentation.
Je vous encourage également à approfondir vos recherches pour mieux comprendre et maîtriser ces notions.