Principe sec dans la programmation : un aperçu complet (2022)

Principe sec dans la programmation : un aperçu complet (2022)

Utilisation excessive du principe DRY

Savoir quand utiliser DRY et quand ne pas l’utiliser est la clé pour écrire des codes propres, réutilisables et robustes.

Chaque ligne de code n’a pas besoin d’être unique.

Parfois, la duplication peut convenir au contexte et le DRY-ing peut introduire des complexités inutiles dans la base de code.

Alors, comment savez-vous quand utiliser le principe DRY ou simplement continuer et vous répéter ?

Pour comprendre cela, vous devez d’abord comprendre comment fonctionne le code propre ;

Votre code peut progressivement devenir désordonné.

Cela devient de plus en plus compliqué au fil du temps, la plupart du temps sans que vous le sachiez.

Mais, c’est votre travail d’adopter de bonnes pratiques pour garder la base de code propre et maintenable.

Un code propre est beaucoup plus facile à lire pour les humains car il utilise des noms corrects et pertinents pour ses fonctions et ses variables.

Il a également moins de complexité, c’est-à-dire moins de conditionnels, car notre cerveau est limité à traiter des scénarios complexes.

Cela étant dit, Permettez-moi de vous présenter à SOLIDE.

Il s’agit d’un acronyme simple désignant cinq principes ou directives qui peuvent vous aider, en tant que développeur, à écrire du code propre, simple, maintenable et réutilisable.

Dans SOLID, chaque lettre est importante, mais elles peuvent être identifiées et pratiquées séparément.

S – signifie “principe responsable unique” [SRP].

Les bases de code écrites avec ce principe sont conformes et ont tendance à être plus propres.

En effet, chaque unité (fonctions, méthodes, classes, packages, etc.) est spécialisée dans un seul travail.

En cas de modifications ou de correctifs, vous saurez où chercher en premier.

Par exemple, une méthode qui sélectionne un élément ET utilise cet élément pour faire quelque chose peut être divisée en deux méthodes, l’une qui sélectionne et l’autre qui agit sur l’élément sélectionné.

En utilisant ce principe, vous vous retrouvez avec moins de bugs.

Vous pouvez comprendre votre code facilement car il y a moins de code à lire.

Votre base de code est beaucoup plus simple à composer, et donc de bons candidats pour assécher la base de code.

O – signifie “principe ouvert-fermé” [OCP].

Ce principe a à voir avec les unités ouvertes pour les extensions mais fermées pour les modifications.

Cela signifie que les classes, les modules, les fonctions et les packages doivent permettre d’étendre leurs comportements sans modifier leur code source.

Si vous souhaitez implémenter une modification prise en charge sur ces unités qui composent votre base de code, vous devriez pouvoir le faire sans modifier le code à de nombreux endroits.

L – signifie “principe de substitution de Liskov” [LSP]

En programmation orientée objet, ce principe stipule que les fonctions qui utilisent des pointeurs ou des références à des classes de base doivent pouvoir utiliser des objets de classes dérivées sans le savoir.

LSP concerne les interfaces et les contrats, ainsi que la façon de décider quand étendre ou non une classe.

En utilisant une analogie, nous savons tous qu’une autruche est un oiseau, mais c’est un oiseau qui ne peut pas voler.

Ensuite, dans notre programme, une autruche est un sous-type de la classe “oiseau”.

Pendant ce temps, le vol est une méthode définie dans la classe des oiseaux.

Dans ISP, le sous-type autruche ne doit pas être amené à utiliser la méthode “voler” définie dans la classe oiseau.

Si cela se produit, vous enfreindrez le principe LS.

Ce principe vous aide à modéliser de bonnes hiérarchies d’héritage.

I – signifie “principe de ségrégation d’interface” [ISP]

Cela stipule qu’un client ne devrait pas être obligé de dépendre ou d’implémenter des méthodes ou des interfaces qu’il n’utilise pas.

Ici, les clients font référence à des pages Web, des applications mobiles, d’autres systèmes ou des développeurs.

Dans ISP, vous concevez des interfaces qui ne donnent à vos clients que ce dont ils ont besoin au lieu de leur donner une interface à usage général.

Par exemple, puisqu’un client peut commander des hamburgers, des frites ou les deux, nous décidons de mettre les options pour passer toutes les commandes sur une seule interface.

Ce principe aide à réduire les effets secondaires de l’utilisation d’interfaces plus grandes en divisant les interfaces d’application en plus petites.

Les unités de vos codes conformes au FAI définissent clairement ce pour quoi elles ont été conçues.

D – signifie “principe d’inversion de dépendance” [DIP]

Ce principe stipule que les modules de haut niveau ne doivent pas dépendre des modules de bas niveau pour leur implémentation, mais doivent plutôt s’appuyer sur leur abstraction.

Comprendre les principes SOLID vous aidera à décider quand diviser vos fonctions et méthodes en fonctions plus petites et réutilisables afin que vous puissiez voir les parties de votre code qui peuvent bénéficier du principe DRY.

Cet article sur FreeCodeCamp explique les notion de SOLIDE

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *