Questions sur la POO dans MQL5 - page 25
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Il existe des statistiques détaillées ici https://githut.info/, mais il s'agit de l'année 14.
Statistiques fraîches sur github https://madnight.github.io/githut/#/pull_requests/2019/2
Je pense que tout le monde gagnerait à lire l'avis des professionnels dans cet article.
Bonne chance
Je pense que tout le monde gagnerait à lire l'avis des professionnels dans cet article.
toutes les conclusions (totalement biaisées) de l'article sont contrebalancées par une simple question.
La PF existe depuis longtemps, pourquoi a-t-elle encore un si petit créneau si elle est si géniale ?
Je ne veux pas dire par là que OOP est le meilleur concept ou que OP est nul.
toutes les conclusions (totalement biaisées) de l'article sont balayées par une simple question.
La PF existe depuis longtemps, pourquoi a-t-elle encore un si petit créneau si elle est si géniale ?
Cet article apporte la réponse à cette question. Vous ne l'avez pas lu attentivement.
L'article apporte une réponse à cette question.
Totalement biaisé et à propos de rien.
Il y a des développeurs qui écrivent réellement le code. Il y a des managers qui ne savent pas du tout comment programmer.
La pile technologique n'est donc pas nécessairement choisie par les développeurs. Et si une certaine pile permet à une équipe de résoudre un problème plus efficacement, il n'est pas nécessaire de connaître et de posséder la technologie pour la comprendre.
Pensez-vous toujours que l'article répond à la question ?
Je pense que tout le monde gagnerait à lire l'avis des professionnels dans cet article.
Bonne chance
Voici l'habituel. Des points de vue extrêmes. C'est comme une discussion sur ce qui est le mieux - un marteau ou une massue.
Vous n'écrirez pas de bons outils en C# mais en C pur, vous vous fatiguerez à décrire et déboguer des chaînes logiques ramifiées dans une application sérieuse.
Cet article n'est donc d'aucune utilité.
C'est toujours comme ça. Des points de vue extrêmes. C'est comme une discussion sur ce qui est le mieux - un marteau ou une massue.
Vous n'écrirez pas de bons outils en C# mais en C pur, vous vous fatiguerez à décrire et déboguer des chaînes logiques ramifiées dans une application sérieuse.
Cet article n'a donc aucun intérêt.
Il y a, bien sûr, une part de vérité dans cet article... au moins, que l'héritage va "tirer" des méthodes et des champs qui ne sont pas vraiment nécessaires, mais hélas, il faut payer pour tout - cela permet de gagner du temps, mais cela peut augmenter l'utilisation de la mémoire ou les performances globales d'une solution, mais cinq pas si triste, le niveau des compilateurs et l'optimisation du code est très raide maintenant, de sorte que le résultat se traduit souvent par une bonne solution pour un temps de développement court
à propos de C#, eh bien, comme si le but qu'il a d'autres, il est purement un "langage Windows" pour obtenir rapidement des résultats sur un PC particulier ou un groupe limité de PC, même si pas installé les mises à jour .Net peut causer des erreurs critiques sur les PC qui n'ont pas accès, et attraper cela est assez coûteux - a écrit un panneau pour le commerce en C# déjà vérifié sur une machine virtuelle, si pas installé tous les "patch" dans les mises à jour, le projet ne peut pas sortir de façon prévisible ;) Bien sûr, vous pouvez essayer d'écrire pour la version la plus récente de .Net, mais il y a un problème - toutes les nouvelles sur GitHub sont postées sous les nouveaux builds .Net - c'est-à-dire que vous serez limité uniquement à leurs développements.
En général, comme ailleurs - l'innovation est "douloureuse, longue et triste", vous devez suivre les tendances fixées par les géants de l'informatique, puis tout est écrit rapidement et sans problèmes, eh bien Microsoft a écrit tout ce qu'ils pouvaient dans le style OOP, vous devez utiliser tout cela ou écrire à partir de zéro tous leurs WinForm, etc. des milliers de tonnes et de téraoctets de code écrit depuis Win-95))))
il y a certainement une part de vérité dans cet article...
Un peu ? ) En fait, c'est comme ça. Cependant, l'auteur ne révèle pas la vérité, c'est une sorte de choses évidentes (du moins pour moi). Je pensais que tout programmeur avec de l'expérience arrive à la même réalisation des problèmes de changement d'état. Au fait, j'ai récemment vu un article très similaire mais plus court. Mais peut-être s'agit-il de l'éternel débat entre les fonctionnalistes et les programmeurs de logiciels libres).
Mais en fait, personne ne vous empêche d'utiliser la POO correctement. L'auteur lui-même mentionne que vous pouvez utiliser des objets immuables. Et 99% des problèmes décrits disparaissent immédiatement. Donc tout dépend uniquement de la question des mains droites et de la tête sur les épaules, et non du paradigme utilisé.
Même si, bien sûr, le fait que les langages de POO les plus répandus ne fournissent pas les moyens de contrôler la variabilité des objets complique le processus. Ainsi, il serait vraiment cool d'avoir le mot-cléimmuable au lieu de const/readonly.
En ce qui concerne les raisons de l'impopularité des langages fonctionnels, je ne suis pas d'accord avec l'auteur ici. Tout d'abord, il est plus compliqué de percevoir un tel code, comme il me semble. Ce n'est pas seulement une opposition entre la POO et la PF, mais une opposition entre les approches impératives et fonctionnelles. La première est plus proche et intuitive pour la plupart des gens à comprendre, à mon avis. Je ne connais les langages fonctionnels que par correspondance, je ne peux donc pas les juger objectivement, mais quand, par exemple, je vois du code surchargé de lambda, cela provoque une dissonance cognitive : c'est trop compliqué et compliqué. Et probablement que la plupart des gens le pensent aussi ;)
En outre, les langages fonctionnels ne sont pas conçus pour un certain nombre de tâches liées à l'interaction avec l'environnement externe, comme par exemple les interfaces graphiques. Lorsque, d'une manière ou d'une autre, vous devez stocker l'état globalement modifié entre les événements.
Un peu ? ) En fait, c'est exactement le cas. Cependant, l'auteur ne révèle pas les Amériques, ces choses sont plutôt évidentes (du moins pour moi). Je pensais que tout programmeur avec de l'expérience arrive à la même réalisation des problèmes d'un état changeant. Au fait, j'ai récemment vu un article très similaire mais plus court. Mais peut-être s'agit-il de l'éternel débat entre les fonctionnalistes et les programmeurs de logiciels libres).
Mais en fait, personne ne vous empêche d'utiliser la POO correctement. Même l'auteur mentionne que vous pouvez utiliser des objets immuables. Et 99% des problèmes décrits disparaissent immédiatement. Donc tout dépend uniquement de la question des mains droites et de la tête sur les épaules, mais pas du paradigme utilisé.
Bien que, bien sûr, le fait que les langages de POO populaires ne fournissent pas de moyen de contrôler la variabilité des objets complique le processus. Il serait cool d'avoir le mot-clé immuable au lieu de const/readonly.
De toute façon, rien ne changera dans un avenir proche, les géants de l'informatique soutiennent ce paradigme, il peut être bénéfique de forcer les développeurs de logiciels à faire des implémentations complexes qui nécessiteront un matériel plus puissant pour fonctionner, ainsi que de présenter leur documentation pour les OS ou les compilateurs avec des bibliothèques prêtes à l'emploi sous forme de POO, ce qui oblige les développeurs ..... et ainsi de suite jusqu'à l'infini ;)
Nous pouvons considérer cette histoire de POO comme la connaissance obligatoire du latin par les médecins - ce n'était pas nécessaire, mais comme moyen de communication au niveau professionnel, il fallait l'utiliser ;)