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 Les principes de design SOLID pour JavaScript

Les principes de design SOLID pour JavaScript

Favoris

Derick Bailey, auteur et développeur focalisé sur le JavaScript, a déclaré dans une récente présentation à CodeMash qu'alors que beaucoup de développeurs ont travaillé avec des langages orientés objet et que beaucoup développent actuellement en JavaScript, très peu utilisent les principes orientés objet en JavaScript. Dans la programmation orientée objet, nous parlons de fondations et de principes comme base pour notre travail, mais lorsque nous passons de langages basés sur des classes statiques à des langages faiblement typés, non basés sur des classes, nous rencontrons souvent des difficultés pour appliquer ces mêmes principes.

Derick affirme qu'il existe beaucoup de bons principes, des pratiques et des patterns pour aider les développeurs à écrire du code JavaScript stable et de bonne qualité, comme par exemple les principes SOLID, identifiés par Robert C. Martin au début des années 2000.

Derick commence par décrire les principes SOLID comme cinq patterns distincts qui s'accordent bien ensemble et les présente ensuite à l'aide d'exemples de code, en soulignant certaines particularités de JavaScript qui rendent l'application de ces principes un peu différente de lorsqu'on le fait avec des langages comme Java et C#.

Les définitions de Derick pour ces cinq principes sont :

  • Le Principe de Responsabilité Unique (Single Responsibility Principle). Tout ne devrait avoir qu'une seule raison de changer. Cela aidera les développeurs à comprendre le contexte et la responsabilité de ce qu'ils sont en train de concevoir et à comprendre quand il y aura besoin d'apporter des changements.
  • Le Principe d'Ouverture-Fermeture (Open-Closed Principle). Un changement de comportement doit être possible sans changer le code existant, par exemple en utilisant des points d'extension et en écrivant du code qui peut s'y accrocher.
  • Le Principe de Substitution de Liskov (Liskov Substitution Principle). Les objets ou les types dérivés doivent pouvoir se substituer à leurs types de base. Pour Derick il s'agit d'une version plus précise du principe d'Ouverture-Fermeture.
  • Le Principe de Ségrégation des Interfaces (Interface Segregation Principle). Un client ne doit pas être contraint de dépendre d'interfaces qu'il n'utilise pas. Le problème est qu'il n'y a pas d'interfaces explicites en JS, cependant il y a des manières de contourner ce point.
  • Le Principe d'Inversion des Dépendances (Dependency Inversion Principle). Ce principe est composé de deux concepts. Le premier précise que nous devons dépendre d'abstractions et non pas d'une implémentation concrète, le deuxième indique qu'une implémentation de bas niveau doit dépendre de concepts de haut niveau.

Derick termine en déclarant que si vous avez dans votre système de gros modules de code monolithiques, les principes SOLID vous aideront à les casser et à les répartir en modules individuels. Cela ne diminuera pas la complexité, mais cela vous aidera à concevoir des abstractions et à remonter des détails dans des concepts généraux sur lesquels vous pourrez raisonner.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT