La conception de bas niveau (LLD) est une phase critique du développement logiciel qui comble le fossé entre la conception de haut niveau et la mise en œuvre réelle. Alors que la conception de haut niveau se concentre sur les plans architecturaux, LLD traite de la manière dont chaque composant, classe ou fonction est mis en œuvre pour répondre aux exigences globales du système.

En termes plus simples, LLD implique la conception de classes, de méthodes, d'interfaces et d'interactions entre elles, garantissant que le code est efficace, maintenable et évolutif. Il s'agit d'une compétence essentielle pour les ingénieurs logiciels, en particulier lors de la création de systèmes qui doivent être robustes, réutilisables et faciles à modifier au fil du temps.

Ce blog vous présentera les concepts, principes et techniques clés impliqués dans la conception de bas niveau et montrera comment ils peuvent vous aider à écrire un code meilleur et plus maintenable.

La première question qui nous vient à l'esprit est :

Pourquoi la conception de bas niveau est-elle importante ?

1. Maintenabilité : une conception bien pensée facilite la maintenance, l'extension et le débogage du code. Une mauvaise conception entraîne une dette technique, rendant les changements futurs coûteux.
2. Évolutivité : un bon LLD garantit que votre code est évolutif, à la fois en termes de performances et de prise en charge de nouvelles fonctionnalités à mesure que le système évolue.
3. Réutilisabilité : des composants bien conçus peuvent être réutilisés dans différentes parties d'un système ou dans des projets entièrement différents.
4. Clarté : grâce à une conception bien définie, les ingénieurs peuvent comprendre comment les différentes parties du système s'articulent, facilitant ainsi la collaboration.

Pour combler le fossé entre les concepts LLD et le code réel, décomposons le processus de conception d'un diagramme de bas niveau en étapes suivantes :

Étape 1 : Principes orientés objet
Étape 2 : Principes SOLIDES
Étape 3 : Modèles de conception

Principes orientés objet

Concept de programmation orientée objet 4 piliers sont indispensables pour commencer à apprendre la conception de bas niveau. J'ai déjà abordé ce concept dans un bref blog de paiement

Principes SOLIDES

S : principe de responsabilité unique (SRP)

• Chaque unité de code ne doit avoir qu'une seule responsabilité.
• Une unité peut être une classe, un module, une fonction ou un composant.
• Maintient le code modulaire et réduit les couplages étroits.

Exemple : Imaginez une classe qui gère à la fois l'authentification et la journalisation des utilisateurs. Si nous devons modifier le fonctionnement de la journalisation, nous finirons par modifier également la classe d'authentification. Cela viole le SRP. Au lieu de cela, nous devrions avoir deux classes distinctes : une pour l'authentification des utilisateurs et une autre pour la journalisation, de sorte que chaque classe ait une seule responsabilité.

O : principe ouvert/fermé (OCP)

• Les unités de code doivent être ouvertes pour extension mais fermées pour modification.
• Étendez les fonctionnalités en ajoutant un nouveau code, sans modifier le code existant.
• Utile dans les systèmes basés sur des composants comme une interface React.

Exemple : considérons un système de traitement des paiements qui gère les paiements par carte de crédit. Si vous devez ajouter la prise en charge de PayPal, plutôt que de modifier le code existant, vous devez l'étendre en ajoutant une nouvelle classe pour les paiements PayPal. Cela garantit que le système existant reste stable tout en permettant l'ajout de nouvelles fonctionnalités.

L : Principe de substitution de Liskov (LSP)

• Les sous-classes doivent pouvoir être substituées à leurs classes de base.
• Les fonctionnalités de la classe de base doivent être utilisables par toutes les sous-classes.
• Si une sous-classe ne peut pas utiliser la fonctionnalité de la classe de base, elle ne devrait pas figurer dans la classe de base.

Exemple : si nous avons une classe Bird qui a une méthode fly() et que nous créons une sous-classe Penguin, qui ne peut pas voler, cela viole LSP. La classe Penguin ne doit pas hériter de fly() car elle modifie le comportement attendu. Au lieu de cela, la classe Bird devrait être refactorisée pour gérer les oiseaux qui peuvent et ne peuvent pas voler différemment.

I : Principe de ségrégation d'interface (ISP)

• Fournissez plusieurs interfaces spécifiques plutôt que quelques interfaces à usage général.
• Les clients ne devraient pas dépendre de méthodes qu'ils n'utilisent pas.

Exemple : Supposons que nous ayons une interface Animal avec les méthodes fly(), swim() et walk(). Une classe Dog qui implémente Animal serait obligée de définir fly(), ce dont elle n'a pas besoin. Pour nous conformer au FAI, nous devrions diviser l'interface Animal en interfaces plus petites comme Flyable, Swimmable et Walkable pour éviter d'imposer des méthodes non pertinentes sur les classes

D : Principe d'inversion de dépendance (DIP)

• Dépendez d'abstractions, pas de classes concrètes.
• Utilisez des abstractions pour découpler les dépendances entre les parties du système.
• Évitez les appels directs entre les unités de code, utilisez des interfaces ou des abstractions.

Exemple : Dans une application e-commerce, si le processus de paiement (module de haut niveau) dépend directement d'une passerelle de paiement spécifique comme PayPal (module de bas niveau), changer de passerelle de paiement nécessite de modifier le processus de paiement. En introduisant une abstraction, telle qu'une interface PaymentProcessor, le processus de paiement peut fonctionner avec n'importe quel mode de paiement sans avoir besoin de connaître les spécificités de PayPal ou de tout autre service.

Modèles de conception

Les modèles de conception sont des solutions éprouvées aux problèmes courants qui surviennent dans la conception de logiciels. Il s'agit de bonnes pratiques que les développeurs peuvent suivre pour résoudre des problèmes de conception spécifiques de manière efficace et systématique. Au lieu de réinventer la roue, les modèles de conception fournissent une approche standard pour résoudre les problèmes récurrents.

Les modèles de conception peuvent être classés en trois types :

1. Modèles de création : gérer la création d'objets

   • Modèle de conception d'usine
   • Modèle de conception d'usine abstrait
   • Modèle de conception du constructeur
   • Modèle de conception de prototype
   • Modèle de conception Singleton

2. Modèles structurels : gérer la composition et les relations des objets

   • Modèle d'adaptateur
   • Modèle de pont
   • Motif composite
   • Motif de décorateur
   • Motif de façade
   • Modèle de poids mouche
   • Modèle de proxy

3. Modèles comportementaux : gérer l'interaction et la responsabilité des objets

   • Modèle de chaîne de responsabilité
   • Modèle de commande
   • Modèle d'interprète
   • Braquette du médiateur
   • Motif souvenir
   • Modèle d'observateur
   • Modèle d'état
   • Modèle de stratégie
   • Modèle de méthode de modèle
   • Modèle de visiteur

Maintenant que nous avons jeté les bases en explorant les principes SOLID et en présentant le vaste paysage des modèles de conception, nous sommes prêts à approfondir ! Dans la prochaine série, je détaillerai chaque modèle de conception avec des exemples pratiques et des scénarios réels. Que vous commenciez tout juste votre parcours de conception ou que vous cherchiez à perfectionner vos compétences, ces modèles vous aideront à écrire un code plus propre et plus évolutif. Restez à l'écoute pour le prochain blog, où nous dévoilerons le premier modèle de conception, étape par étape !

Si vous êtes arrivé jusqu'ici, n'oubliez pas de cliquer sur J'aime ❤️ et de laisser un commentaire ci-dessous si vous avez des questions ou des idées. Vos commentaires comptent énormément pour moi et j'aimerais avoir de vos nouvelles !