Le message contient une certaine quantité de plaisanteries, le ministère de la Santé demande de manière convaincante à un lecteur non préparé de s'abstenir de lire.Les articles sur le thème «La FA est meilleure» ou «La POO est meilleure» ressemblent à un débat sur ce qui est le mieux pour le déjeuner, une fourchette ou une cuillère. Traditionnellement, les junes commençaient avec une cuillère, mais quelqu'un de très autoritaire m'a dit une fois qu'il ne mange que de la viande et utilise une fourchette, donc une nouvelle mode est apparue - manger avec une fourchette. Ils mangent de la bouillie et des soupes et parviennent même à faire des smoothies. Internet regorge d'articles, à quel point nous sommes bons, que nous avons appris à manger un smoothie avec une fourchette et à surmonter tous les râteaux. C'est à la fois drôle et triste, d'une part, cela donne un avantage concurrentiel aux gars expérimentés qui montrent de super résultats en ignorant simplement ce battage médiatique, d'autre part, ils doivent recycler leurs collègues et employés, nettoyer les ordures causées par le vent de leur tête. Dans cet article, je vais essayer de dire ma vision, qui ne prétend pas être une vérité absolue, mais qui fonctionne très bien dans la pratique
Comme il est de coutume en science, nous commençons par les définitions. La définition classique de la POO implique de suivre les principes d'héritage, d'encapsulation et de polymorphisme. Mais si nous n'avons pas l'un de ces composants, ce sera OOP? Et sinon, quel sera-t-il?
Tandis que la partie ennuyeuse du public planait sur cette pratique et ne nous posait aucune question, rappelons-nous ce qui s'est passé avant l'OLP . Et avant lui, il y avait la programmation procédurale. Et l'idée principale de la POO à l'époque était la
connexion des données et des fonctions pour leur traitement . L'idée est simple, mais assez révolutionnaire, il est difficile d'imaginer combien, mais plus à ce sujet plus tard.
La programmation fonctionnelle, dans une interprétation libre, considère le
programme comme une formule mathématique . Les formules sont bien formalisées et avec la même entrée retournent la même sortie. L'ensemble du programme se compose de routines qui suivent les mêmes principes. En quoi cela diffère-t-il de la même programmation procédurale? FP utilise activement
des fonctions pures ; idéalement, le programme entier devrait être une fonction pure. Les fonctions pures
n'ont pas d'effets secondaires , elles peuvent être facilement mémorisées, testées facilement, etc ... On peut dire que dans les fonctions pures l'idée principale et l'avantage du FP.
Et maintenant deux questions:
- Peut-on utiliser des fonctions pures en POO?
- Peut-on lier des fonctions aux données dans le FP?
La réponse à tous les deux est oui. Les méthodes de classe statiques peuvent être pures, même les méthodes d'instance peuvent être considérées comme propres si elles ne créent pas d'effets secondaires et nous considérons les propriétés de l'instance de classe comme des paramètres. Les limites des définitions classiques sont gonflées et certains peuvent être en désaccord, mais en pratique, cela fonctionne. Et ces méthodes sont formalisées et testées pas pire que les fonctions pures classiques écrites selon tous les canons. La liaison des méthodes aux données est un peu plus compliquée, le langage et les bibliothèques utilisés imposent des restrictions. Disons qu'en JavaScript, cela se fait de manière élémentaire, pas sûr de Haskell et Erlang. Maintenant, la chose la plus intéressante est ce qu'elle donne et pourquoi la POO a déjà soulevé un tel battage médiatique il y a 20-30 ans. Si vous écrivez un petit programme - vous pouvez écrire comme vous le souhaitez, sauf pour votre sens de la beauté, cela n'affecte rien. Lorsque vous créez un très gros programme, un problème de complexité se pose. Pas de complexité informatique, nous pensons qu'ici nous faisons tout bien, mais de complexité perçue. Disons que vous disposez de 50 000 lignes de code, et toutes sont utiles. Comment les organiser pour ne pas devenir fou (ou ne pas quitter le travail à 11 nuits)? Nous ne pouvons pas réduire le nombre d'opérations, mais nous pouvons réduire le nombre de connexions entre elles (l'encapsulation nous y aide). Nous masquons l'implémentation complexe derrière une interface simple et continuons à travailler uniquement avec l'interface. Par exemple, Internet est une chose terriblement compliquée, mais la plupart des développeurs ont suffisamment de connaissances du protocole HTTP pour faire leur travail
et laisser le réseau, les niveaux physiques et autres aux administrateurs système . Plus la connectivité de nos modules est faible,
moins la complexité au stade de leur intégration les uns avec les autres. Moins un module connaît l'autre, moins il est connecté. Les méthodes de liaison aux données à l'intérieur du module nous aident à nous débarrasser de ces connaissances des consommateurs du module. C'est le principal avantage pragmatique de la POO. Sur quoi? Approche ci-dessus sans liaison de données et de méthode. FP, comme nous l'avons découvert, ne dit rien à ce sujet. Vous pouvez passer des classes comme arguments à des fonctions pures, ou vous pouvez utiliser des fonctions pures comme méthodes d'une classe, cela ne se contredit pas, mais la complète seulement.
Dans la pratique, où fonctionne principalement une approche et où est principalement l'autre? Lorsque j'écris un
backend sur NodeJS, cela se révèle en quelque sorte dans un paradigme
fonctionnel . Pourquoi? Parce que la demande au serveur est par nature une fonction, avec une entrée et une sortie fixes. L'approche fonctionnelle tombe très naturellement sur les demandes des serveurs et le code est plus compact et flexible. Lorsque je crée une
interface pour le navigateur, la
POO fonctionne généralement mieux, car en plus des entrées et des sorties, nous avons également un
flux d'événements utilisateur , ainsi que des événements de programme, tels que le début et la fin des animations, des demandes de serveur, etc. ... L'approche fonctionnelle a fonctionné s'il ne s'agissait que de dessiner une page statique sans interactivité, lors de l'utilisation du FP en frontend, le temps soit interactif soit de développement en souffre (selon nos mesures, toutes les 3 fois). Pourquoi?
Tout paradigme de programmation est basé sur un certain modèle de réalité, et un modèle est toujours une simplification. En PF, le modèle impose plus de restrictions au monde, il est donc plus facile à formaliser. Pour la même raison, lorsqu'il devient hors de propos aux conditions du problème, il commence à nécessiter plus de béquilles. Par exemple, les IF frontaux ont résolu le problème de la saisie des utilisateurs en créant un tableau d'événements (actions, redux hi). Mais il s'agit d'une abstraction non pertinente qui, en plus de son impact sur les performances, augmente considérablement le temps de développement. Avec cette approche, vous pouvez créer une liste de tâches, mais sur de très gros projets, vous devez casser des briques avec votre front, puis écrire des articles victorieux pour les mêmes malheureux. À titre de comparaison, lorsque nous avons écrit le terminal d'échange (sur vanilla js, bien sûr) avec canvas, svg et mis à jour plusieurs fois par seconde via des websockets, dans certains composants fréquemment mis à jour, nous n'avons pas supprimé les div, mais les avons réutilisés, car les recréer est relativement cher opération dans le navigateur (et cela est important si vous avez une
très grande application ). Si vous programmez sur le front-end, vous n'aurez même pas une telle pensée, car vous avez déjà accepté l'immuabilité (à propos, c'est une chose merveilleuse pour travailler avec le multithreading, ce qui
ne se produit pas dans JS), de sorte que chaque action passe par chaque réducteur. et autres déchets. D'un autre côté, dans le backend, il s'avère souvent ne pas avoir de classes du tout, car là, juste, vous pouvez éviter le coût de leur création, car les conditions des tâches sont très pertinentes pour le modèle FP. Mais, pour la plupart, les développeurs Java et PHP ne sont pas pressés d'étudier le FP, les fournisseurs frontaux sont en première ligne, qui en ont vraiment le moins besoin. Comme exercice pour l'esprit - bien sûr, c'est intéressant, seuls les programmes sont obtenus g ... mais, et quelqu'un d'autre les utilise. Malgré le fait que le frontend est une section relativement jeune de l'informatique et ses tâches non résolues depuis plusieurs générations. Ce qui, semble-t-il, n'est pas un exercice pour l'esprit?