Un point de vue intéressant sur l'OLP
Ce n'est pas un problème avec la POO, mais avec son application, et encore plus avec ceux qui l'appliquent. Ce sont eux qui se sentent...
l'enthousiasme, voire l'extase qu'avec l'aide de la POO, vous pouvez écrire de manière incroyablement efficace.
un code incroyablement compliqué (et même y participer :). Ils ont le sentiment d'appartenir à une élite particulière.
Ils ont même inventé leur propre "grand livre" qu'ils lisent et lisent et lisent mais ne peuvent pas
mais ils ne peuvent pas le lire. Cela s'appelle "Design Patterns" - en langage humain
se traduit par "L'art ultime d'écrire du code flou, brumeux et confus". Si, toutefois.
c 'est un truc très, très cool, incroyablement simplificateur et...
simplifie et simplifie la vie.
Voilà, vous êtes toujours soupçonné)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23Vous devez comprendre que ces articles sont très probablement rédigés par des personnes qui ne connaissent pas les PC et leurs crochets déroutants, qui peuvent inclure 20 tabs.....
Ensuite, vous commencez à penser au laconisme et à la commodité de la POO, vous pouvez déclarer une partie de la fonctionnalité à l'avance et ainsi de suite. ..... En substance, la similitude de l'un avec l'autre. C'est juste que de tels articles sont souvent écrits par des personnes qui ne maîtrisent que le code procédural - et celui-ci n'est même pas proche de la FP, donc si vous ne savez pas ce que sont les crochets et l'utilisation vivante de ceux-ci, il n'est pas question de FP...
De plus, bon nombre des "langages en voie d'extinction" énumérés dans l'article prennent en charge toutes les fonctionnalités de la PF et de la POO, pourquoi devraient-ils mourir ? Et certains d'entre eux sont les mieux payésde la CEI.Il s'agit plutôt d'une "spaghettification" en POO, sans aucunement penser à se "noyer" dans la PF. À mon avis, le paradigme procédural est réaliste et plus efficace en termes de ressources que la POO.
juste que le code lui-même est plus long sur oop ? bien, oui, il y a un constructeur et dans certains cas le code est généralement plus long sur oop.... techniquement, le déploiement de la FP devrait être plus efficace pour la génération de code machine..... mais le code ne se simplifie pas et il est impossible de faire des wrappers normaux en ce qui concerne le typage...
de nos jours, on peut souvent trouver un mélange de l'un et de l'autre - les moyens n'interfèrent pas les uns avec les autres
juste que le code lui-même est plus long sur oop ? bien, oui, il y a un constructeur et dans certains cas le code est généralement plus long sur oop.... techniquement, le déploiement de la FP devrait être plus efficace pour la génération de code machine..... mais le code ne se simplifie pas et il est impossible de faire des wrappers normaux en ce qui concerne le typage...
Aujourd'hui, il est souvent possible de voir un mélange de l'un et de l'autre.
Sans la POO et la PF, tout fonctionne plus facilement et plus rapidement (oui, sans les "beautés", les panneaux etc.), mais il est parfois difficile de comprendre même votre code)
Sans la POO et la PF, tout fonctionne plus facilement et plus rapidement (oui, sans "beautés", panneaux, etc.), mais il est parfois difficile de comprendre même son propre code).
Maîtrisez d'abord l'un ou l'autre, ou mieux les deux, et décidez ensuite de ce que vous préférez. Et avec une telle approche comme maintenant, avec le temps, vous vous transformerez en Fedoseev qui est d'accord avec tout ce que vous ne comprenez pas (c'est-à-dire presque tout).
Quelle réaction destructive au sujet et une discussion destructive. Dites-moi, en tant qu'adepte de la programmation procédurale, comment éviter la "spaghettisation" dans la POO, comment analyser et si cela a du sens d'utiliser les "spaghettis" de quelqu'un d'autre ?
Après tout, il s'avère que la POO est surtout destinée à la lisibilité et à la programmation en équipe, c'est-à-dire aux grands projets. Un conseiller expert qui négocie un symbole à son graphique avec le contrôle du risque maximum du solde / fonds dans le compte, bien, ne peut pas être appelé un grand projet - il est suffisant et plus rentable dans la mémoire / vitesse - programmation procédurale.
Questions :
- inconvénients/avantages de la POO (comme impératif) à partir d'une expérience personnelle
- les inconvénients/avantages de la FP (comme déclaratif) à partir d'une expérience personnelle.
Et un avis sur les perspectives est bien sûr intéressant, surtout dans la direction du calcul parallèle. Je ne vois pas l'intérêt d'aborder le sujet des quantum.
Dites-moi, en tant que programmeur procédural, comment éviter la "spaghettisation" dans la POO.
La recette est donnée dans l'article cité : s'efforcer d'écrire des fonctions déterministes.
Comment démonter et est-il judicieux d'utiliser les " spaghettis " de quelqu'un d'autre ?
Du bon code, oui, mais pas du spaghetti.
Après tout, qu'est-ce que vous obtenez, la POO est surtout pour la lisibilité et la programmation en équipe, c'est-à-dire pour les grands projets.
Bien.
Un EA qui négocie un symbole sur un graphique auquel il est attaché avec un contrôle maximal du risque du solde/des fonds du compte, eh bien, ne peut pas être appelé un grand projet - donc la programmation procédurale est suffisante et plus rentable en termes de mémoire/vitesse.
Pour se rendre en Australie, il est plus pratique d'utiliser un avion (OOP), pour se rendre dans une ville voisine, une voiture ou même un vélo suffisent (PP). Il suffit de choisir le moyen le plus pratique pour atteindre l'objectif.
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
Voilà, vous êtes toujours soupçonné)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23