SOLID est-il toujours pertinent dans l’architecture logicielle moderne ?
Daniel Orner a publié un article récent affirmant que les principes SOLID sont toujours le fondement de l’architecture logicielle moderne. Selon Orner, alors que la pratique du développement de logiciels a changé au cours des 20 dernières années, les principes SOLID sont toujours la base d’une bonne conception. L’auteur explique comment ils s’appliquent également à la programmation fonctionnelle et à l’architecture des microservices, avec des exemples.
SOLID est un mnémonique et un acronyme pour cinq principes de conception de logiciels énumérés en 2000 par Robert C. Martin. Selon l’auteur de l’article, ces « principes SOLIDES sont une rubrique éprouvée pour créer de bons logiciels » et peuvent être adaptés aux pratiques modernes d’ingénierie logicielle.
L’auteur souligne certains développements pertinents dans l’industrie du logiciel depuis la création des principes SOLID. Les langages et paradigmes à typage dynamique tels que la programmation fonctionnelle ou la métaprogrammation ont gagné du terrain et sont aujourd’hui monnaie courante dans les logiciels. Il ajoute que les microservices et le logiciel en tant que service ont rendu le modèle de déploiement monolithique moins courant et déclare que de nombreux principes régis par SOLID ne sont plus couramment utilisés par autant de programmeurs qu’auparavant.
D’autres aspects de la conception de logiciels n’ont pas changé, dit l’auteur. Les gens continuent d’écrire et de modifier du code, il est toujours organisé en modules, et il est toujours nécessaire de définir sa visibilité en fonction de sa base d’utilisateurs prévue.
L’auteur propose de reformuler les définitions originales du principe SOLID afin qu’elles deviennent applicables à la programmation orientée objet (OOP), fonctionnelle (FP) ou multi-paradigme et, parfois, aux systèmes basés sur des microservices.
L’auteur réaffirme le principe de responsabilité unique comme « chaque module doit faire une chose et la faire bien ». Outre la POO, la nouvelle définition s’applique également à la programmation fonctionnelle et à la conception de microservices.
Le principe ouvert-fermé devient « vous devriez pouvoir utiliser et ajouter à un module sans le réécrire ». Il est accompli dans FP en utilisant des « points de crochet » et est une caractéristique naturelle de la POO.
L’auteur définit le principe de substitution de Liskov comme « vous devriez pouvoir substituer une chose à une autre si ces choses sont déclarées se comporter de la même manière ». Il s’applique désormais également aux langages de programmation dynamiques à l’aide de fonctions de typage ou de filtrage.
Tel que redéfini par l’auteur, le principe de ségrégation des interfaces devient « ne montrez pas à vos clients plus qu’ils n’ont besoin de voir ». En d’autres termes, documentez uniquement ce que votre client a besoin de savoir. Cette définition est également applicable aux microservices via des déploiements séparés ou des ensembles de documentation séparés.
La définition du principe d’inversion de dépendance reste la même : « dépendre d’abstractions, pas de concrétions ». L’auteur pense que l’abstraction est toujours un concept essentiel, s’appliquant à la POO, à la FP et même aux microservices (utilisant le passage de messages au lieu de la communication directe).
D’autres auteurs ont des points de vue différents sur les microservices. Paulo Merson soutient que les principes SOLID sont bons pour la POO mais ne s’appliquent pas pleinement aux microservices. Par conséquent, Merson propose un autre ensemble de principes pour la conception de microservices : IDEALS. Il s’agit de la ségrégation des interfaces, de la déployabilité, de l’événementiel, de la disponibilité plutôt que de la cohérence, du couplage lâche et de la responsabilité unique.
.