S.O.L.I.D  PAR LA PRATIQUE

Dé nos jours avoir un programme ou une application qui intègrent facilement les nouvelles fonctionnalités sans complication est devenu de plus en rare. Est-ce à cause d'une mauvais approche analytique? Est-ce la mauvaise compréhension aboutissant à un mauvais choix  architecturale? On peut alors se poser autant de questions.

Pour ma part, je pense qu'il ne faut pas sortir des chantiers battus. En effet, le choix d'une architecture au détriment d'une autre doit être un choix sagement nourri en prenant en compte de l'évolutivité des fonctionnalités. Heureusement que des ingénieurs en ingénierie logiciel se sont penchés sur la question en mettant en place des standards approuvés par la majeur partie de la communauté des développeurs. 

Je voudrais partager avec vous sur un ensemble de cinq(5) articles sur les principes S.O.L.I.D mais pas que la théorie, à travers des cas pratiques. 

Dans cet article introductif, nous verrons:

1- Qu'appelle t-on S.O.L.I.D?

2- La définition de chaque principe

2- Avantages et inconvénients

NB: mon objectif est de publier un article par principe en me focalisant sur un ou des cas pratiques. En un mot il s'agira de montrer comment appliquer chaque principe  avec un cas pratique dans un projet concret.

Technologies et outils utilisés:

    - JAVA 17(ou 8+)

    - Springboot 3+

    - Intellij

Sans plus tarder, débutons notre aventure.

1- Qu'appelle t-on S.O.L.I.D?

S.O.L.I.D est un acronyme des cinq premiers principes qui prennent place dans la programmation orientée objet. Ces principes ont été mis en valeurs par Robert C. Martin appelé encore uncle Bob alors consultant chez Xerox. Ces principes s'appliquent à tout langage de programmation de préférence orienté objet. Ces principes reposent sur des bonnes pratiques de développement logiciel, qui tiennent compte non seulement de l'extension ou de l'évolution des fonctionnalités mais aussi contribuent à éviter la production de code touffus donc difficilement maintenable.

Ces principes sous-tendent: la clarté, la maintenabilité et l'évolutivité

 1-a) La clarté

Il s'agit de produire un code simple, pas touffus si possible moins de lignes de codes. Autrement dit n'écrire que ce qui est nécessaire a une classe ou a une fonction.

1-b) la maintenabilité

Ici il s'agit du coût  en terme de temps à passer pour faire une correction si le cas se présente. Plus le code est claire et précis, moins on mettra de temps à le comprendre donc a vite faire les corrections et autres. C'est pourquoi il est fortement déconseiller de prendre en compte dès la phase d'analyse, les bonnes pratiques en matière de qualité de code.

1-c)L'évolutivité

Ici encore il est aussi question de temps. Il faut passer moins de temps à faire évoluer le code. Si chaque évolution doit nous prendre plus de temps soit par ce que celle-ci nous exige de revoir l'existant, alors nous sommes loin d'un code qui intègre l'évolutivité. En parlant ainsi, je fait vraiment abstraction de l'analyse et de l'architecture tout en ayant conscience que parfois le problème peut venir de là également. J'essaie vraiment de rester focus sur l'objectif de cet article.

2- Définition de chaque principe

Comme je l'ai dit plus haut, chaque principe fera l'objet d'un article afin de bien comprendre et de retenir l'essentiel. Je donnerai plus d'informations pour chaque principe. Ces informations viennent de mon expérience personnelle et de ce que j'ai pu lire ou voir dans les projets sur lesquels j'ai travaillés. Je ne dit pas que je vous donnerai tout car il faut vraiment être très modeste par ce que moi même je ne connais pas tout. En plus, tous les exemples seront en Java mais également applicables  dans tous les langages de programmations.

3- Avantages et inconvénients:

A- Avantages

     A-1) La pertinence des principes S.O.L.I.D dans les architectures modernes

 Aujourd'hui, nous remarquons une modernisation des architectures logicielles afin de répondre mieux aux besoins sans cesse changeants. Dans ce contexte, les principes SOLID restent la référence car ils sont la base de toutes bonnes pratiques de model de  conception. En plus, ces principes ont été éprouvés et peuvent s'adapter à toutes pratique modernes de conception.

    A-2) Accroitre la productivité des développeurs

En plus d'avoir un merveilleux impacte sur la l'architecture, les principes SOLID sont aussi bénéfiques aux développeurs qui les appliquent. En effet, ils leurs permettent d'apporter de la  clarté dans leur travail et leurs permettent également de maitriser la charge de travail en jouant sur le facteur temps. Si les principes sont bien maitrisés et appliqués, les équipes de développement mettront moins de temps à greffer les nouvelles fonctionnalités. Ce qui va rependre un écho favorable sur toute la chaine: des concepteurs jusqu'aux testeurs en passant bien évidement par les développeurs. Enfin, à la fin de ce type de projet où les principes SOLID ont été respectés, les développeurs cagneront en confiance pour les plus aguerris et en montée en compétence pour les  juniors.

A-3) Une maitrise du budget

Tout projet sérieux a un chiffrage, c'est ce qui permet de définir en fonction des critères de gestions de projet des limites prévisionnelles tant sur le budget que sur le temps mis pour réaliser ce projet. Les principes SOLID peuvent être à l'origine d'une bonne gestion du budget car, si les  bonnes bases sont adoptées, le reste du travail ne souffrira d'aucun ralentissement ou encore d'aucun blocage. En le disant, je sais bien que des facteurs endogènes peuvent influencer négativement le projet notamment le manque de ressources ou encore le niveau d'expertise ... mais une fois de plus, je reste focus sur l'objectif de cet article en supposant que tous les autres facteurs sont maitrisés.

Il y'a encore plus d'avantages mais permettez-moi de me limiter à ces trois. Je rappelle que c'est un article introductif.

   B) Inconvénients

Il peut avoir beaucoup d'inconvénients car ceux-ci peuvent variés d'un projet à un autre. Nous en citerons  un seul qui est majeur:

- Le manque de ressources qualifiées pour mettre en pratiques ces principes

Prochain article: nous verrons le "S" des cinq principes