Puisque j’ai sans doute mis 30 millions de développeurs en colère avec ma dernière diatribe sur la POO, je voulais m’expliquer un peu plus, puisque je ne déteste pas la POO. En fait, bien au contraire, la POO est incroyable, mais pour moi c’est comme la moitié d’un cerveau. C’est bien d’avoir la moitié d’un cerveau, mais c’est mieux d’avoir tout le cerveau. Et si la POO est la moitié du cerveau, alors les constructions fonctionnelles sont le reste du cerveau.
Avant de continuer, regardez ce code s’il vous plaît. C’est essentiellement un dictionnaire avec une chaîne comme clé et un Fonction (objet lambda fortement typé) comme valeur. Ensuite, réalisez qu’il s’agit d’une structure de programmation fonctionnelle, implémentée en C#. Vous trouverez ci-dessous son code dans son intégralité.
static readonly Dictionary<string, Func<ISignaler, HttpRequest, Task<Node>>> _payloadHandlers =
new Dictionary<string, Func<ISignaler, HttpRequest, Task<Node>>>
{
{
"application/json", RequestHandlers.JsonHandler
},
{
"application/x-www-form-urlencoded", RequestHandlers.UrlEncodedHandler
},
{
"multipart/form-data", RequestHandlers.FormDataHandler
},
};Le point sur le code est bien sûr qu’il me permet de déclarer un objet de fonction de charge utile de requête HTTP associé au Type de contenu valeur de mes demandes. Ensuite, comme mon API reçoit des requêtes HTTP, je peux les gérer en fonction du type de contenu de la requête, en utilisant un bien connu et fortement typé « objet fonction » dans mon code, responsable de la transformation de toutes les charges utiles en un format structuré en interne. Je me réfère à ces bougres comme « délégués symboliques », et moi à deux reprises créé tout un langage de programmation autour de l’axiome.
Créer quelque chose de similaire à ce qui précède sans structures de programmation fonctionnelles, telles que la possibilité de transmettre des fonctions et de les utiliser en tant que citoyens de première classe, serait si difficile que je ne suis même pas sûr de vouloir essayer d’expliquer comment cela devrait être fait. 4/5 modèles de conception différents, 10/15 classes différentes, des usines abstraites et Dieu sait quoi de plus. J’ai déjà mal à la tête…
La construction ci-dessus est cependant ridiculement simple à étendre avec la coutume Type de contenu comme l’illustre la méthode ci-dessous.
public static void RegisterContentType(string contentType, Func<ISignaler, HttpRequest, Task<Node>> functor)
{
_payloadHandlers[contentType] = functor;
}Invoquer la méthode ci-dessus lors du démarrage de votre application en passant par exemple « application/x-foo-bar » et en y associant une fonction, vous obtenez la prise en charge d’un tout nouveau Type de contenu dans vos propres applications. Principe ouvert fermé; Vérifier!
Cependant, ce ne sont pas des constructions POO. Bien sûr, ce sont des fonctionnalités de C #, qui existent depuis une décennie ou quelque chose – Mais ces Fonction objets et action des objets qui nous permettent de créer des anonymes fortement typés « les fonctions » sommes ne fait pas partie de la POO. Ces constructions sont souvent appelées objets Lambda et font partie des langages de programmation fonctionnels depuis que Lisp est sorti des laboratoires il y a plus de 70 ans ou quelque chose du genre. Et lorsque vous pouvez utiliser de telles constructions, elles ont souvent tendance à éliminer à elles seules une demi-douzaine de modèles de conception dans votre code…
Le problème de la façon dont je le vois, c’est qu’au moins lorsque j’ai commencé à programmer pour de vrai il y a plus de 20 ans, tout le fuzz était autour de la POO. Plusieurs de nos titans de l’industrie ont mis en garde contre cela, certains d’entre eux dont je vous ai parlé dans mon ancien article, mais tout était tout à coup censé être résolu à l’aide de la POO. Cette approche est la mauvaise mentalité et conduit à la souffrance. Si vous ne me croyez pas, essayez d’implémenter quelque chose comme la méthode ci-dessus sans pour autant en utilisant mon « Délégué symbolique » approcher. Bien sûr, cela peut être fait, mais la complexité de votre code serait exploser!
Le paradoxe pour moi, c’est que cette approche symbolique du délégué est littéralement une construction si puissante que je « accidentellement » fini par créer un langage de programmation complet avec la chose; Hyperlambda bien sûr. Non seulement il s’agit d’un langage de programmation complet, mais il possède également des caractéristiques assez intéressantes, telles que la possibilité d’automatiser la plupart de la création de mon code, de sorte que je puisse créer des constructions qui créent du code Hyperlambda, câblant automatiquement la plupart de mes pièces. ensemble, ce qui me permet de faire moins de travail, car mon ordinateur fait essentiellement la plupart de mon travail. Il y a quelques mois, j’ai créé un système CRM avec Hyperlambda, et lorsque le système a été mis en production 5 semaines après le début du projet, et que le client était satisfait du résultat, le processus d’échafaudage automatique était littéralement terminé. 83% de mon travail backend. Pour mettre ce chiffre en perspective, imaginez aller voir l’un de vos développeurs backend et lui dire ce qui suit.
Je peux te rendre 5 fois plus productif
Parce que c’est littéralement ce que 83% implique. Bien sûr, ce que le développeur final veut faire de son temps libre dépend de lui. Vous voulez partir en vacances 83 % de votre temps ? Vérifier! Envie de livrer 5 fois plus de projets avec les mêmes ressources ? Vérifier! Cependant, si vous ne profitez pas de telles constructions, d’autres le feront, et vous prendrez du retard à un moment donné, puisque tout le monde est 5 fois plus rapide que vous…
C’est ce que j’appelle O2. Le moment où les constructions fonctionnelles et les constructions POO sont fusionnées en une seule, ce qui permet d’utiliser n’importe quel outil qui s’avère le mieux adapté au travail, en fonction du problème à résoudre. Bien sûr, si vous regardez le code avec lequel nous avons commencé, vous vous rendrez rapidement compte qu’une grande partie du code est du code POO à l’ancienne. Injection de dépendance ? Vérifier! Architecture SOLIDE et usage des interfaces ? Vérifier! Héritage (où cela a du sens) ? Vérifier!
En plus de l’occasionnel Fonction et action objet, vous pourriez presque être induit en erreur en pensant qu’il s’agit simplement d’une POO à l’ancienne – Cependant, ce n’est pas le cas ! Fondamentalement, il s’agit de la synergie de la programmation fonctionnelle avec la programmation OOP, résultant en un répertoire plus large pour vous en tant que développeur de logiciels, vous faisant meilleur à votre travail, capable de résoudre plus de problèmes, en appliquant de meilleures solutions. Cependant, pour pouvoir utiliser de telles constructions, vous devrez modifier votre façon de penser. J’appelle cette modification pour « O2 », l’idée étant que c’est de la POO 2.0 ou quelque chose comme ça…
O2 est la fusion de FP et OOP
… et en appliquant de telles constructions, votre base de code devient plus facile à comprendre, plus extensible, plus encapsulée, ce qui fait que votre bonheur augmente en raison de moins de frustration ! Le travail n’est pas le but, c’est le moyen d’atteindre un autre objectif – Si un processus vous permet de travailler moins, tout en offrant plus, il est crucial que vous le choisissiez. Même si vos seules raisons sont que vous voulez passer votre temps libre à 83% à coder Suite …
L’une de mes inspirations dans la vie est Bruce Lee. Bruce n’est jamais resté coincé « modes ». La POO est une style, mais ce n’est pas le seul style. Faites comme Bruce Lee… ^_^