Hello Jospin, merci à toi, ça fait plaisir à lire 🙂

Pour le coup j’ai une chaîne, je vais justement recommencer à publier plus souvent.

https://www.youtube.com/alexsoyes

Bonne journée à toi,

Alex

très bel article merci d’avoir partagé cela. Je laisse rarement les commentaires sur les blogs mais vu le travail abattu tu l’as bien mérité. Je suis développeur PHP/Laravel mais je ne connaissais pas du tout le principe SOLID, j’en ai eu vent en fouillant comment m’améliorer sur le web. Les exemples sont clairs et compréhensibles. Merci encore! Si t’as une chaîne Youtube je serai ravi de m’abonner.

Salut Ziane, merci pour ton commentaire 🙂

Tu aurais un exemple sous la main ? J’avoue que part défaut dans mon code, j’utilise beaucoup d’interfaces à droite à gauche, notions métiers ou pas !

Au plaisir,

Alex

Je voulais juste nuancer l’explication donnée pour le DIP. Il me semble que ce principe invite à éviter d’utiliser des implémentations de bas niveau dans du code de haut niveau (metier) mais plutot d’utiliser les abstractions (classes abstraites ou interfaces) des ces implémentations. Ceci afin d’eviter le couplage, de pouvoir changer d’implementations ou la modifier sans impacter le haut niveau.
Mais peut etre que ta definition s’entends dans le monde php plus que dans le monde java.

Merci

Bonjour,

C’est vrai que mon idée sur le sujet a bien changé depuis mon article sur le DDD.

Par contre je ne savais pas que les principes SOLID venait d’Uncle Bob !

Merci pour ton commentaire, une petite mise à jour de l’article s’impose 🙂

Alex

Le SRP ce n’est pas se résumer à une action spécifique par exemple une classe qui permet de changer le mail d’un utilisateur. Il faut raisonner par contexte, à savoir d’un coté une classe qui permet d’appliquer les règles de gestions donc une entité ou un agrégat et de l’autre une classe qui permet de gérer la persistance en base de donnée.

Cela veut dire que sur le SRP on peut avoir un Entité User qui nous permet d’appliquer tout un tas de règles métier / gestion avec un multitude de méthode mais que l’on a aucun lien vers le contexte base de données.
Pour être plus précis : la responsabilité unique de mon entité c’est d’agréger les données les mon utilisateurs en appliquant certaines règles, la responsabilité de mon repository c’est de manipuler ces données dans un stockage quelconque .

Cf.  »Clean Architecture » par Robet C. MARTIN – page 57 – Principe SRP

Hello !

Merci pour ton message, trop cool d’avoir laissé un feedback aussi long.

1) Quand tu parles de clarté de code tu fais référence à la partir où je dis que c’est « plus facile à lire » ?

2) Pour l’équilibre c’est clairement quelque chose que j’ai dû revoir personnellement, parce-que j’ai pas mal changé là-dessus, sur ça d’ailleurs et sur le principe DRY en lisant beaucoup sur le DDD.

Néanmoins je reste persuadé qu’un fichier doit s’inclure dans un groupe avec des actions précises pour qu’il ne soit pas « fourre-tout ».

Je peux toujours changer d’avis mais… 🙂

3) J’ai dû relire plusieurs fois et ça m’a fait du bien.

function sell(Car $car): void // ❌ Declaration of CarManager::sell(Car $car): void must be compatible with VehicleManager::sell(Vehicle $vehicle):

Qu’on soit d’accord, on parle de ça ?

C’est le principe de la contravariance des arguments (dans la définition d’une implémentation, on ne peut remplacer le type/classe d’un argument d’une fonction/méthode qu’avec un type parent du type initial).

Ici on ne parle que de PHP ou de manière générale ?

Sur ce point j’ai un peu de mal, car j’aime l’idée qu’un enfant puisse se substituer à son parent dans la définition d’une classe fille.

Mais je me trompe probablement sur la manière de penser la chose.

De la même manière si la classe mère dit « cette méthode prend des poissons » et que dans la classe fille il est dit « cette même méthode prend désormais tout animal qui vit dans l’eau » c’est également ok selon le LSP.

Super intéressant ça… Tu trouves ça ok toi ? Si je lis bien l’enfant renvoie une exception plus large que le parent, et ça me gène.

AnimalException > AnimalVivantDansLeauException > NestPasUnPoissonException

Je verrais plus les choses dans cet ordre qu’avec un ordre un peu… aléatoire ?

En tout cas merci beaucoup pour ton message, ça me faitréfléchir et je reviendrais sûrement modifier l’article dans les moments à venir.

Au plaisir,

Alex

Rappeler les principes SOLID avec des exemples c’est vraiment une chouette idée. Par contre, il y a quelques points qui, pour moi, constituent un problème.

1) La clarté du code ne dépend pas des principes SOLID. On peut écrire du code illisible avec les meilleurs principes, ce sont deux choses distinctes. D’où la nécessité d’avoir des normes d’écriture à part, souvent intégrées dans les linters, parce que suivre des patterns et principes n’a jamais rendu le code propre.

2) Les gros fichiers vs la séparation en plein de petits fichiers est également un choix de norme, et ne relève pas des principes SOLID. Un des plus gros fichiers que j’ai vu en prod faisait 12 600 lignes, et était parfaitement lisible, et à l’inverse j’ai vu des codes avec pleins de petits fichiers et une arborescence très logique mais illisible pour les dévs de l’équipe parce que c’était trop éclaté et qu’il fallait changer de fichiers tout le temps, entraînant l’abandon du code. Il est plus intéressant de chercher l’équilibre 😉

3) Le LSP, là c’est problématique, il y a plusieurs soucis.

3) 1. Le second exemple est très compromis, PHP ne faisant pas d’erreur. Les arguments d’une méthode/fonction, selon le principe de Liskov, ne peuvent pas imposer des restrictions supplémentaires, comme le fait une classe enfant. Par conséquent la classe enfant (ie. « Car ») ne peut pas remplacer la classe « Vehicule », puisqu’elle est plus spécifique. C’est le principe de la contravariance des arguments (dans la définition d’une implémentation, on ne peut remplacer le type/classe d’un argument d’une fonction/méthode qu’avec un type parent du type initial). PHP agit donc correctement sur ce point en respectant le LSP. De la même manière, on peut considérer les appels à « order » avec « Car » et « Boat » parce que les deux classes étendent « Vehicule » ce qui permet de les mettre au même niveau via le DIP, et non le LSP (en effet le LSP rentrerait dans ce cadre en contradiction avec lui-même, mais en réalité théoriquement ça s’explique, c’est juste non trivial).

3) 2. Concernant les points suivants :
=> La signature des fonctions doit être identique entre l’enfant et le parent
=> Le retour de la fonction doit retourner le même type que le parent
=> Les exceptions retournées doivent être les mêmes
Je suppose qu’il s’agit d’une volonté de simplification, mais je pense que c’est allé un peu trop loin. Les règles de Liskov-Wing sont plus souples que ça :
=> La signature n’a pas à être identique en type, mais uniquement en taille (ie. même nombre d’argument, et même nombre de résultat (1 ou 0))
=> Les arguments de la fonction de l’objet enfant doivent être du même type ou d’un type parent que celui de la fonction de l’objet parent
=> Le retour et les exceptions doivent être du même type ou d’un type enfant
Par exemple, si la classe définit en interne des sous-classes de l’exception c’est ok. De la même manière si la classe mère dit « cette méthode prend des poissons » et que dans la classe fille il est dit « cette même méthode prend désormais tout animal qui vit dans l’eau » c’est également ok selon le LSP.

Je rejoins complètement l’aspect maintenabilité et l’évolutivité, qui sont en effet des avantages implicites des principes SOLID, et les exemples sont très pertinents et ajoute une vraie plus-value sur la compréhension des principes.

De la même manière la différence entre SRP et ISP est bien marquée et bien exprimée, avec le bout de code ça rend vraiment bien (juste éviter le « éviter les grosses interfaces rendra le code plus facile à lire », ça c’est juste un avis personnel, pas un effet des principes).

Bonne continuation.

Hey Zak !

Pas vraiment.

Il faut que les fonctions de ta classes soient limitées au scope… de ta classe.

Donc pas nécessairement une fonction par classe.

Ta classe, c’est ton périmètre, tes frontières, elle a un contexte et elle doit le garder.

Chaque fonction de ta classe doit (en théorie) rester dans ses frontières et ne pas impacter les autres.

Si ça t’intéresse il y a un gros article sur le DDD – Domain-Driven Design, qui pourra te donner d’autres pistes de reflexion 🙂

Bon courage,

Alex

Merci pour ton article 🙂

Du coup pour la partie « Single Responsability Principle ». Ça veut dire qu’il faut faire « une fonction = une classe » ?

Dans ton exemple, tu as UsersService.php qui a 5 fonctions. Ça veut dire qu’une fonction est égale à une classe dans ce résonnement.
Ce n’est pas un peu « bizarre » ?

Salut Ulrich,

Merci à toi pour ton message, c’est cool de savoir que ça peut aider et t’aider à progresser !

Reviens donner des nouvelles de ton avancée 👋

Yes exact !

Cet use-case serait donc un objet injecté dans le contrôleur et qui prendrait en paramètres les différentes classes effectuant chaque tache.

Dans ce cas je créerais un use-case qui lui reprendrait toutes les injections.

Ton contrôleur lui ne serait qu’un point d’entrée pour appeler le use-case avec les bonnes informations 🙂

Pour le use-cae c’est lui qui fera les différentes étapes dont tu parles au dessus.

De cette manière, on garde le principe intact

Et bien un workflow très simple basé sur l’exemple de la gestion des utilisateurs.

* Un user s’identifie sur l’application, on utilise `UserAuthenticatorService.php` pour l’authentifier.
* Si celui-ci est inscrit, il faut persister l’utilisateur dans la session via `UserSessionService.php`
* Admettons que il existe dans l’application un système de statistiques des connexions utilisateurs, il faudrait enregistrer cette connexion via un service `UserLoggerService.php` par exemple.

Sachant que ces objets peuvent avoir des dépendances, comme `UserAuthenticatorService` qui devrait avoir une dépendance vers un système de stockage via une interface par exemple, pour récupérer l’utilisateur qui tente de se connecter.

En utilisant un framework comme symfony par exemple, cela fait beaucoup de service a injecter dans le contrôleur pour gérer le workflow d’authentification.

Salut Laurent,

A priori si tu suis les principes de la clean architectures tu devrais arriver à bien séparer tout ça (voir mon article sur le DDD).

Tes services doivent décrire des actions métiers, donc tu peux :

* soit leur passer plusieurs objets si ils concernent la même action
* soit encapsulé tout ça dans un nouvel objet (un agrégat racine), et c’est la méthode que je te recommande

Tu veux bien me donner un exemple précis voir comment je peux illustrer ?

👊

Concernant le premier principe et l’exemple fournit comment faire pour gérer tout ces objets ensemble ? Il y a 4 objets à faire travailler ensemble pour gérer un utilisateur, est ce que le fameux service UserManager peut être conservé pour orchestrer ceux ci ? Un exemple d’utilisation comme pour les autres principes serait top 👍

Tu as aimé « Clean code » du coup ? Tu l’as lu en français ?

Merci pour ton message en tout cas 🙂

Hey bonjour 👋

J’avoue que je suis assez content de la manière dont il a été construit, d’autant plus si ça remarque ; merci beaucoup à toi pour ton commentaire !

Les tutoriels trop théoriques c’est tout ce que je déteste 😇

« J’ai écrit cet article car beaucoup de tutoriels en informatique sur SOLID montrent des exemples d’utilisation avec des objets que je n’utilise jamais. »

Elle est si vrai ! Cela me fait penser que vous avez mis le doigt sur un problème récurrent de beaucoup de tutoriel, trop fantastique, trop métaphorique, trop théorique.

Encore merci !

Merci beaucoup ! En effet je te conseille de le mettre en favoris, moi-même j’y reviens régulièrement 😇

Tu étais solide avant l’heure 😉

Hello !

Du tout, les interfaces vont te permettre de simplifier la gestion de tes classes et de tes entités. C’est super propre comme manière de faire.

Hello ! Merci à toi pour ton commentaire !

Tu parles du principe Ouvert/Fermé et du principe de substitution de Liskov ? C’est une différence d’interprétation plus qu’une différence technique. Les interfaces permettent de cibler les éléments communs, ceux qui doivent se comporter de manière assez similaire. Le principe de Liskov permet aussi de faire ça, sauf qu’ici on parle d’un parent et d’un enfant, ce qui conceptuellement est différent.

Par exemple, la plupart du temps on utilise des interfaces quand il s’agit de DI et les classes parentes lorsqu’un enfant a les mêmes fonctionnalités que son parent (un contrôleur sur Symfony par exemple).

Pas forcément facile à appréhender tout ça, je te conseille de relire l’article de temps en temps 🙂

Bon été,
Alex

Hey Vincent,

Au départ je n’avais pas non plus de class dans ma première app React.

Au fur et à mesure, j’en ai eu besoin pour simplifier le fonctionnement (ajout de méthodes dans les classes entités notamment).

Je ne sais pas si c’est une bonne chose en revanche !

Pour répondre à ta question, ce n’est pas simple.

• L : Si jamais tu n’utilises pas l’extension et que tu préfères par exemple la composition, eh bien c’est vite réglé, ce n’est possible qu’en utilisant des classes.
• I : Vu que tu utilises des interfaces tu peux les composer grâce à de plus petites interfaces. Par exemple dans mon projet React, j’ai une EntityInterface qui comporte name: string et id: number que j’utilise en paramètre des composants HTML de type select ou encore checkbox. Ce qui rejoint le point du dessous.
• D : Il vaut mieux passer une interface EntityInterface qu’un objet User par exemple en paramètre, mais toi vu que tu n’utilises pas d’objet de type « Class »…

À chaud, voici ce que je répondrais 🙂

Mais c’est loin d’être absolu, la programmation fonctionnelle est un monde à part entière que je ne maîtrise pas totalement.

Merci pour ton commentaire.

Alex

Je suis dev web mais je ne m’occupe pas du backend, et autant je me rend compte que j’applique le S et le O, autant le reste j’ai du mal a voir comment les appliquer sur un appli React/Redux en Typescript, car j’essaye au maximum d’avoir une approche de programmation fonctionnel, je n’ai aucune « Class », et les interfaces que j’utilise sont la pour décrire mes types.

Est ce que les principes SOLID sont réservé à la POO ?