BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités SOLID Est-Il Toujours Pertinent Dans L'architecture Logicielle Moderne ?

SOLID Est-Il Toujours Pertinent Dans L'architecture Logicielle Moderne ?

Favoris

Daniel Orner a publié un article récent soutenant que les principes SOLID sont toujours le fondement de l'architecture logicielle moderne. Selon Daniel Orner, si la pratique du développement logiciel 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 SOLID constituent une rubrique éprouvée pour la création de bons logiciels" et peuvent être adaptés aux pratiques modernes de génie logiciel.

L'auteur souligne certaines évolutions pertinentes dans l'industrie du logiciel depuis la création des principes SOLID. Les langages à typage dynamique et les paradigmes tels que la programmation fonctionnelle ou la métaprogrammation ont gagné en popularité et sont aujourd'hui monnaie courante dans les logiciels. Il ajoute que les microservices et les logiciels en tant que service ont rendu le modèle de déploiement monolithique moins courant et affirme que de nombreux principes régis par SOLID ne sont plus couramment utilisés par autant de programmeurs qu'auparavant.

Les autres aspects de la conception des logiciels n'ont pas changé, selon l'auteur. Les gens continuent d'écrire et de modifier le code, il est toujours organisé en modules, et il est toujours nécessaire de définir sa visibilité en fonction de la base d'utilisateurs à laquelle il est destiné.

L'auteur propose de reformuler les définitions originales des principes SOLID afin qu'elles deviennent applicables à la programmation orientée objet (POO), fonctionnelle (FP) ou multi-paradigme et, parfois, aux systèmes basés sur les microservices.

L'auteur reformule le principe de responsabilité unique comme suit : "chaque module doit faire une chose et la faire bien". En plus de la POO, la nouvelle définition est également applicable à la programmation fonctionnelle et à la conception de microservices.

Le principe open-closed devient "vous devriez pouvoir utiliser et ajouter à un module sans le réécrire". Il est accompli en FP en utilisant des "hook points" et est une caractéristique naturelle de la POO.

L'auteur définit le principe de substitution de Liskov comme suit : "vous devriez pouvoir remplacer une chose par une autre si ces choses sont déclarées pour se comporter de la même manière". Il s'applique maintenant aussi aux langages de programmation dynamiques à l'aide du duck typing ou des fonctions de filtrage.

Tout comme redéfini par l'auteur, le principe de séparation des interfaces devient "ne montrez pas à vos clients plus que ce qu'ils ont besoin de voir". En d'autres termes, ne documentez que ce que votre client a besoin de savoir. Cette définition est également applicable aux microservices par le biais de déploiements séparés ou d'ensembles de documentation distincts.

La définition du principe d'inversion de dépendance reste la même : "dépendre des abstractions, pas des implémentations". L'auteur estime que l'abstraction reste un concept essentiel, s'appliquant à la POO, à la PF, et même aux microservices (utilisant les échanges de messages au lieu de la communication directe).

D'autres auteurs ont des perspectives différentes concernant 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, Paulo Merson propose un ensemble différent 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é par rapport à la cohérence, du couplage lâche et de la responsabilité unique.

 

Evaluer cet article

Pertinence
Style

Contenu Éducatif

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

BT