Code Super SEC

SEC signifie « Ne vous répétez pas » et est sans doute l’un des principes de conception les plus importants lorsque vous créez du code, quel que soit le langage que vous utilisez. Les raisons sont simples ; Parce que chaque fois que vous répétez le code, vous devez modifier plusieurs endroits si vous devez changer votre logique. Par conséquent, si vous ne créez pas de code DRY, vous obtenez un logiciel pléthorique, répétant les mêmes constructions, au point qu’il devient impossible à maintenir. Par conséquent, la définition même de DRY est que votre code est réutilisable, ce qui implique que vous pouvez sans doute quantifier à quel point votre code est DRY, en vous demandant dans quelle mesure votre code est réutilisable. La POO a cependant un défaut fondamental qui rend ridiculement difficile la création de code DRY, ce qui est mieux expliqué par la célèbre citation suivante sur la réutilisation dans la POO…

Vous voulez la banane, mais vous obtenez un singe tenant une banane dans la forêt tropicale !

Ce qui précède essentiellement « encapsule » (même!) le problème avec la POO en tant que mécanisme permettant d’obtenir la réutilisabilité, et si vous n’êtes pas d’accord avec moi, veuillez créer un peu plus de code POO, jusqu’à ce que vous soyez d’accord avec moi, auquel cas votre opinion compte… 😉

La semaine dernière, j’ai organisé un cours Hyperlambda pour 3 développeurs ukrainiens se rendant explicitement à Chypre uniquement pour apprendre Hyperlambda de moi, et en particulier l’un de mes participants était extrêmement actif en me donnant des suggestions d’améliorations. Deux de ses suggestions étaient cependant particulièrement intéressantes, et j’aimerais donc les partager puisqu’elles font maintenant partie du cœur de Magic. Et même si vous ne vous souciez pas de Magic, il y a peut-être encore des leçons à tirer des idées.

Intercepteurs

Un intercepteur dans Hyperlambda revient (presque) à injecter quelque chose dans votre pipeline ASP.NET 5. Fondamentalement, cela implique un morceau de code Hyperlambda, qui enveloppe votre point de terminaison Hyperlambda, où vous pouvez mettre tous les points communs, pour rendre votre code plus SEC. Par exemple, imaginez le code suivant.

.arguments
   name:string
data.connect:[generic|some-database]
   data.read
      table:users
      columns
         username
   return:x:@data.read/*

Le code ci-dessus est un exemple typique de fichier de point de terminaison Hyperlambda. Cependant, vous avez souvent des dizaines de ces mêmes fichiers dans le même dossier, et un parcelle de leur code est similaire. De plus, ce n’est pas vraiment de nature générique et ne permet pas de changer par exemple le nom de la base de données que vous utilisez. Imaginons donc que nous voulions changer le nom de la base de données, lui permettant d’être un paramètre de configuration à la place.

.arguments
   name:string
config.get:"acme:foo:database-connection-string"
data.connect:x:-
   data.read
      table:users
      columns
         username
   return:x:@data.read/*

OK, alors maintenant le code est légèrement meilleur en ce qui concerne le « Principe ouvert fermé », puisque nous pouvons y appliquer des modifications, sans avoir à modifier le code lui-même. Cependant, avec des dizaines de ces fichiers dans le même dossier, à un moment donné, nous réaliserons que nous répétons la même chose [config.get] et [data.connect] invocation maintes et maintes fois. Depuis la dernière version de Magic, nous pouvons utiliser « intercepteurs » pour éviter de nous répéter. Illustrons en créant un intercepteur remplaçant notre ci-dessus « mouiller » code.

config.get:"acme:foo:database-connection-string"
data.connect:x:-
   .interceptor

Ce qui précède est un intercepteur, et le résultat de la création du fichier ci-dessus en tant que « intercepteur.hl » fichier, est que nous finissons maintenant par éviter de nous répéter, car nous pouvons maintenant modifier le fichier de point de terminaison pour qu’il devienne le suivant.

.arguments
   name:string
data.read
   table:users
   columns
      username
return:x:@data.read/*

Nous n’avons supprimé que deux lignes de code de notre exemple Hyperlambda d’origine, mais non seulement la chose ne se répète pas potentiellement sur des dizaines ou des centaines de fichiers, mais elle est également beaucoup plus lisible. Par conséquent, en utilisant intelligemment des intercepteurs, nous simplifions beaucoup la lecture de notre code, en plus de cela, notre code devient plus SEC. Cependant, le coût est que tout le code en cours d’exécution ne se trouve pas dans le même fichier. C’est un petit coût pour la lisibilité ajoutée, et la réutilisabilité ajoutée, je dirais.

Maintenant, bien sûr, vous pouvez également imbriquer les intercepteurs vers le haut dans votre hiérarchie de dossiers, ce qui entraîne l’application récursive de plusieurs intercepteurs, ce qui vous permet de créer des extraits de code assez intelligents en conséquence, où le code final exécuté est en fait le résultat concaténé d’une demi-douzaine de fichiers différents, s’appliquant récursivement vers le haut dans votre hiérarchie à vos fichiers intercepteurs. Regardez-moi démontrer l’idée dans la vidéo suivante.

En plus d’utiliser des intercepteurs dans Hyperlambda, vous pouvez également utiliser des gestionnaires d’exceptions globaux, déclarés au niveau du dossier, de la même manière que les intercepteurs sont déclarés. Bien sûr, les gestionnaires d’exceptions ne sont pas imbriqués et appliqués de manière récursive, mais c’est à peu près la même structure que les intercepteurs, ce qui implique que vous déclarez votre gestionnaire d’exceptions une fois, et tous les fichiers de ce dossier et vers le bas dans la hiérarchie utiliseront par défaut votre gestionnaire d’exceptions nouvellement créé .

La partie vraiment cool de ceci est que vous pouvez réellement changer globalement le comportement de votre application si vous le souhaitez, en appliquant un seul intercepteur et un seul gestionnaire d’exceptions à votre module, vous permettant de créer des produits partiels en tant que micro-services, et/ou de modifier d’autres aspects de votre application en combinant des intercepteurs et des gestionnaires d’exceptions avec les fonctionnalités dynamiques d’Hyperlambda. Si vous souhaitez lire plus de détails à ce sujet, vous pouvez consulter la documentation de style tutoriel pour les intercepteurs sur le lien suivant.

L’une des différences cruciales entre la version Hyperlambda de celle-ci et la version plus traditionnelle de la POO où vous injectez des éléments dans votre pipeline, comme par exemple ASP.NET Core, etc. et les objets lambda, l’intercepteur est chargé d’injecter dans l’objet lambda en cours d’exécution, vous offrant beaucoup plus de capacités DRY que la POO, au prix d’avoir à imaginer les choses qui ne sont pas là (encore !) lorsque vous créez votre point de terminaison Fichiers hyperlambda. Je soupçonne que ce dernier sera une fonctionnalité que j’apprécierai profondément moi-même au fil du temps, et je m’habituerai davantage à ces gars-là. Le paradoxe est que c’est sans doute « meilleur OOP que OOP et plus de code SOLID que SOLID », même s’il n’y a pas une seule méthode virtuelle, aucune interface et aucune classe nulle à voir de toute façon, d’où …

Pas de singe, pas de forêt tropicale, mais toujours une banane ^_^

Ou « Code Super SEC » …