Frais généraux de l'OLP - page 2
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
Bien sûr, la belle POO doit être payée avec des ressources et beaucoup de temps de débogage. La POO n'a de sens que comme enveloppe de texte pratique ou avec une utilisation minimale dans l'initialisation de l'exécution... En fait, la POO n'était qu'un truc marketing de Microsoft pour augmenter les coûts des heures de travail des programmeurs et pour stimuler l'achat d'équipements plus avancés. Et ils ne sont pas idiots eux-mêmes et écrivent tous les logiciels en C et en assembleur.
Quelle connerie.
tout le monde sait que les programmeurs MS écrivent directement en code machine
chaque programmeur a un livre avec les codes machine du processeur sur son bureau et ils gravent juste les codes sur des cartes perforées.
Bill Gates peut compiler un système d'exploitation dans sa tête).
Quel tas de conneries.
Tout le monde sait que les programmeurs MS écrivent directement en code machine.
Votre clownerie n'est pas très claire, il est connu que les insertions en langage assembleur sont utilisées pour améliorer les performances du code...
Je peux supposer que la POO est utilisée dans le terminal au minimum ou pas du tout parce qu'il est difficile d'obtenir des fichiers aussi compacts sans grandes bibliothèques externes comme dans dotnet....
Avez-vous des arguments valables sur l'essence de ce qui a été dit ?
Vérifiez. Alexei est en effet juste en train de réagir émotionnellement. Et en substance, les objections sont les suivantes.
La POO est très utile lorsque vous devez supporter un code complexe.
Il est certain que cela n'a aucun sens d'appliquer toutes les astuces OOP à un indicateur-MA. Cependant, lorsque des classes de base sont écrites - même pour MA - l'approche OOP est au moins aussi bonne que l'approche procédurale habituelle.
Le principal avantage de la POO se révèle avec le support des structures d'objets développées. Lorsque l'encapsulation garantit l'absence de la nécessité de comprendre à chaque fois toutes les nuances des fonctions surchargées. Lorsqu'elle est basée sur le polymorphisme, laréutilisation du code devient beaucoup plus importante.
L'essence de la POO est plus proche du monde réel où tout objet est toujours lié à ses propriétés et possède certaines règles d'interaction avec l'environnement.
En ce qui concerne le "coût accru des heures de travail", ce n'est pas vrai. Il est certain que la conception d'un système dans le style POO nécessite un peu plus de travail que dans l'approche procédurale. Toutefois, ces coûts supplémentaires sont plus que compensés par la facilité de maintenir et de modifier le code écrit.
Personnellement, j'écris de très petits indicateurs "écrits sur le genou" sans aucun objet. Cependant, lorsque quelque chose de plus (au moins multiplateforme) est nécessaire, j'utilise toujours le style POO et les pratiques existantes dans les bibliothèques d'objets.
Votre clownerie n'est pas très claire, nous savons que les insertions en langage assembleur sont utilisées pour améliorer les performances du code...
Je peux supposer que le terminal utilise un minimum ou pas de POO, car sans d'énormes bibliothèques externes comme dans dotnet, il est difficile d'obtenir des fichiers aussi compacts...
1. la POO - elle est d'une grande aide lorsque vous devez supporter un code complexe.
2. Bien sûr, il n'y a aucun sens à appliquer toutes les astuces OOP pour l'indicateur-MA. Bien que, lorsque les classes de base sont écrites - même pour MA - il s'agit toujours d'une approche OOP, du moins, pas pire que l'approche procédurale habituelle.
3. Le principal avantage de la POO se révèle avec le support des structures d'objets développées.
1. Par exemple ? Les slogans accrocheurs, c'est bien, mais on ne sait pas exactement ce qu'ils signifient...
2. Il a déjà été dit que la POO est bonne en tant qu'enveloppe de texte, mais c'est parce qu'elle n'a pas été perfectionnée dans la programmation procédurale.
3) Pourquoi devons-nous multiplier ces "structures avancées" ? Il sera destructeur pour les performances du code et il n'est pas certain qu'il sera plus facile et plus rapide d'y détecter les bogues.
Les compilateurs modernes optimisent plusieurs fois mieux qu'un programmeur moyen ou même bon.
Peut-être que certaines choses simples et triviales le peuvent, mais seulement parce que des personnes se sont assises et ont écrit manuellement l'algorithme, mais si quelque chose de non standard, c'est loin d'être certain, surtout si des fonctionnalités OOPesheh s'y trouvent.
Dans les pilotes, oui, ils utilisent l'assebler, mais pas à cause de la vitesse, c'est juste plus facile de travailler avec le matériel..,
Les gens ne sont pas stupides - pourquoi voudraient-ils quelque chose de compliqué et de déroutant qui soit aussi lent ?
Et par exemple ? Les slogans accrocheurs, c'est bien, mais il est difficile de comprendre ce dont on parle exactement... 3.
2. Il a déjà été dit que la POO est bonne en tant qu'enveloppe de texte, mais c'est parce qu'elle n'a pas été portée à son comble dans la programmation procédurale.
3) Pourquoi devrions-nous multiplier ces "structures développées" ? Ce serait terrible pour les performances du code et ce n'est pas le fait qu'il sera plus facile et plus rapide d'y détecter les bogues.
1. Par exemple, vous avez besoin d'un tableau d'objets. Les problèmes commenceront lorsque vous devrez modifier le comportement des objets, par exemple en les ajoutant, en les supprimant ou en les triant. Dans la POO, le support d'un tableau de pointeurs proprement dit et son utilisation sont inclus dans les objets de base. La modification des objets descendants qui sont effectivement contenus dans le tableau n'a aucune incidence. En style procédural - modifier des objets réels qui sont en fait contenus dans un tableau - affecte généralement beaucoup plus d'endroits, au moins parce que nous devons tenir compte des changements de taille des objets. Ce qui entraînera plus facilement des erreurs.
Multiplateforme - également beaucoup plus pratique à organiser dans le style OOP. Lorsque nous demandons, par exemple, une position commerciale, nous obtenons une interface, et peu importe la plateforme sur laquelle nous travaillons, l'interface offre des fonctions virtuelles, sur lesquelles nous pouvons obtenir toutes les données sur tous les ordres (pour MT4) ou les positions (MT5), et, du point de vue de l'expert, il n'y a aucune différence. Le conseiller expert n'a pas besoin de savoir sur quelle plateforme il travaille.
2. Eh bien, "finir en programmation procédurale" signifie "écrire des objets-procédures", c'est-à-dire créer des liens entre les données et les procédures, qui représentent les objets dans la POO.
3. et puis nous avons, disons, un certain nombre de types d'ordres, qui ont beaucoup en commun. Il serait raisonnable de créer un objet COrderInfo - qui serait l'objet de base, et ses descendants représenteraient différents types d'ordres. Dans ce cas, le processeur de transaction (j'ai la classe CTradeProcessor) prendra automatiquement en charge exactement cet ordre, qui lui a été transmis, par les procédures qui sont nécessaires pour traiter cet ordre.
Il est plus facile de détecter les bogues lorsqu'il y a moins de liens croisés. Ce qui est exactement fourni par l'encapsulation et le polymorphisme. Nous demandons l'interface de la position commerciale (CTradePositionI) et toutes les connexions avec les classes réelles qui représentent cette position (CMT4PositionInfo,CMT5PositionInfo) sont effectuées uniquement par le biais de cette interface, ce qui contribue précisément à une correction des erreurs plus facile que si nous travaillons directement avec les fonctions réelles qui renvoient les données de la position commerciale.