Règles de structure. Apprendre à structurer des programmes, explorer les possibilités, les erreurs, les solutions, etc. - page 10
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
Je ne suis pas étranger à la programmation d'État et l'ai moi-même utilisée pendant plusieurs années. Cependant, après avoir utilisé cette méthode pendant un certain temps, j'ai décidé de l'abandonner et j'ai développé un modèle de trading plus transparent, plus simple et plus adapté sur sa base.
Lisez attentivement cet article : L 'auto-programmation comme nouveau moyen de créer des systèmes de trading automatisés.
Lisez ensuite attentivement les commentaires qui y sont consacrés.
Ensuite, contemplez très, très attentivement une plaque disgracieuse de l'article, et pensez à ce qu'elle pourrait signifier :
Si, après avoir lu tout cela, vous vous dites toujours "Ouah ! La programmation d'État, c'est trop cool !". - Eh bien, comptez là-dessus.
J'ajouterais que le principal problème de la programmation des États est constitué par les situations qui produisent beaucoup de modes inutiles (voir colonne N État). Dans la programmation de l'État, chaque mode doit décrire ses propres règles séparément. Expliquons par un exemple, disons que nous sommes en mode achat. Tout va bien jusqu'à ce que le robot décide d'ouvrir une position supplémentaire. Et pourquoi pas ? Les conditions de sortie de l'ancienne position n'ont pas été remplies et il est trop tôt pour la fermer, alors qu'un nouveau signal ne doit pas être manqué. Et c'est là que les problèmes commencent, car au moment de l'arrivée d'un nouveau signal, le robot est en mode Achat, alors que les règles d'ouverture d'une nouvelle position sont en mode État (attente et recherche de nouveaux signaux d'entrée). Maintenant, en mode Achat, nous devons redécrire les mêmes règles d'ouverture de position qui sont utilisées en mode Etat. Et si une nouvelle position est de sens contraire (couverture) ? Ce poste est ouvert, mais qu'en faire ? Après tout, sa logique de gestion est décrite en mode Vente, alors que le robot est en mode Achat. Nous pouvons simplement passer en mode vente, mais que faire de la position d'achat restante ? En général, dans ce cas, nous devons écrire un autre mode inutile comme BuyAndSell. La redondance des modes produit une autre situation : une seule et même action est effectuée par différentes sections de code. En somme, pour ceux qui aiment le désordre de la programmation exponentielle, c'est le meilleur.
"C'est comme ça, Mihalych" (c)... C'est ce à quoi je fais allusion, aussi.
(fcplm)
Pas du tout.
Je pensais juste que si MQL5 supportait l'héritage multiple et qu'une classe pouvait déclarer des méthodes abstraites, cela ouvrirait une voie pour utiliser les interfaces, ce qui serait génial pour les grands projets.
Les méthodes abstraites ne sont pas explicitement interdites (j'utilise souvent une notation alternative),
Et l'héritage multiple serait un énorme plus.
Les méthodes abstraites ne sont pas explicitement interdites.
Pour citer Rosh: en quoi cela vous aide-t-il à scier du bois de chauffage ?
La FAQ de Von est assise sur un quadruplet et se fiche éperdument des méthodes abstraites et de l'héritage multiple.
Peu importe qu'il y ait des méthodes abstraites ou non, de toute façon, la tâche de structuration du projet ne sera pas résolue.
D'ailleurs, plus il y a de variantes de mise en œuvre d'un même produit, plus il est difficile de choisir la variante à utiliser.
Il s'avère donc que le programmeur est souvent bloqué dans la tâche de la beauté du code. C'est un art pour l'amour de l'art.
J'ai remarqué, en général (en parlant pour moi), que plus il y a de timbres de planification de projet, plus c'est facile.
Ensuite, vous pouvez changer, modifier, re-modifier, sur-modifier,
Mais le cadre initial (même s'il n'est pas génial) donne le ton de toute la construction.
Pour citer Rosh: En quoi cela vous aide-t-il à scier du bois de chauffage ?
Ensuite, vous pouvez changer, re-modifier, re-modifier, re-modifier,
mais le cadre initial (même s'il n'est pas génial) donne le ton de toute la construction.
La vitesse de sciage du bois de chauffage augmentera.
Si vous avez déjà une idée claire de ce à quoi vous devez ressembler, vous pouvez probablement tout faire intelligemment dans MQL4.
Et si cette notion n'existe pas, cela signifie qu'il y aura beaucoup de changements et d'ajouts. Et l'héritage multiple permet des changements avec des coûts minimes.
Je suis d'accord avec les méthodes abstraites - c'est juste une belle forme d'enregistrement.
La vitesse de sciage du bois de chauffage augmente.
Si vous avez déjà une idée claire de ce à quoi vous devez ressembler, vous pouvez probablement tout faire intelligemment dans MQL4.
Et si vous n'avez pas une telle idée, cela signifie beaucoup de changements et d'ajouts. Et l'héritage multiple, en particulier, permet d'apporter des changements avec des coûts minimes.
Aujourd'hui, on essaie d'abandonner l'héritage au profit de l'inclusion. Pouvez-vous imaginer l'attitude à l'égard de l'héritage multiple ?
FAQ:
Pas du tout.
Ce n'est pas le cas. En utilisant un interrupteur... et l'utilisation d'un modèle de machine à états sont deux choses différentes. On peut lire dans le texte qu'il n'y a pas de modèle, comme dans l'article que vous avez cité.
On peut y lire quelque chose comme "J'ai inventé un système de gain unique..." et ensuite une déclaration de Martin tordue.