Programmation OOP vs programmation procédurale - page 38
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
MonOnInit() ressemble à peu près à la même chose - une douzaine de lignes...
Et alors ?
Wow !
Je me demandais : existe-t-il un autre moyen, dans la programmation moderne, de faire échouer un problème au niveau d'un noyau ?
Quant au fait qu'il s'agit de l'ensemble du programme... il n'y a rien d'autre :-)
Bien sûr que non.
Tout le reste en cendres + R (il ne compte pas)
Le débogage consiste à déboguer la logique : l'intersection de deux mashas est là, mais le signal ne l'est pas. Il y a des problèmes pour comprendre les valeurs des variables à partir du terminal. L'essentiel ici est de ne pas changer de type de compte et, de préférence, de ne pas changer de courtier.
Je ne connais pas toutes ces passions qu'ils écrivent ci-dessus.
Bien sûr que non.
Tout le reste en cendres + R (il ne compte pas)
Le débogage consiste à déboguer la logique : l'intersection de deux mashas est là, mais le signal ne l'est pas. Il y a des problèmes pour comprendre les valeurs des variables à partir du terminal. L'essentiel ici est de ne pas changer de type de compte et, de préférence, de ne pas changer de courtier.
Je n'ai connaissance d'aucune des passions décrites ci-dessus.
Franchement, avez-vous un compte réel ? Les passions sont juste issues des rencontres avec le monde réel et des meurtrissures de l'exploitation/entretien... et pour un testeur, peu importe sur quoi et comment écrire...
La POO est une méthode pour séparer, envelopper et cacher les parties d'un mécanisme. C'est au développeur de décider si cela est nécessaire ou non. Cela n'a absolument rien à voir avec l'augmentation de l'efficacité du mécanisme. Cela structure la façon de penser, oui. On ignore si elle le structure correctement ou non. La nécessité d'une telle mesure dépend de la personne concernée.
Il y a toujours un problème quand on écrit des fonctions :
1. vous écrivez une fonction
2. vous écrivez une autre fonction et vous voyez qu'elle est très similaire mais différente de la première.
Il y a toujours un dilemme : doit-on regrouper tout en un ou en garder deux ? Vous obtenez un code plus polyvalent mais plus compliqué. Vous obtenez un code simple mais un grand nombre de fonctions. C'est comme ça que ça se passe avec cette OOP.
Si vous parvenez à allouer un petit nombre de classes bien structurées et claires,
si vous écrivez beaucoup de conseillers experts
si vous les modifiez souvent pour une raison quelconque
ALORS
La POO est utile.
Si ce n'est pas le cas, il n'est pas nécessaire de se remplir la tête d'informations qui n'ont rien à voir avec le commerce, et il vaudrait mieux consacrer du temps à la recherche.
Bonne chance à vous tous !
Seulement franchement - au moins un compte réel... Les passions viennent des collisions avec le monde réel et des meurtrissures de l'exploitation/de la maintenance... et pour le testeur, peu importe sur quoi et comment écrire...
Depuis 2008, y compris PAMM.
Aucun problème d'entretien.
Mais avec l'exploitation...
L'écart est augmenté jusqu'à 20, puis la marge est multipliée, puis l'écart, puis la lumière est éteinte..... puis ma femme essuie la poussière sur les boutons tactiles... J'en ai assez. C'est pourquoi cette branche est comme en Chine.
Il y a toujours un problème quand on écrit des fonctions :
1. vous écrivez une fonction
2. vous écrivez une autre fonction et vous voyez qu'elle est très similaire, mais différente de la première.
Il y a toujours un dilemme : doit-on regrouper tout en un ou en garder deux ? Vous obtenez un code plus polyvalent mais plus compliqué. Vous obtenez un code simple mais un grand nombre de fonctions. C'est comme ça que ça se passe avec cette OOP.
Si vous parvenez à allouer un petit nombre de classes bien structurées et compréhensibles,
si vous écrivez beaucoup de conseillers experts
si vous les modifiez souvent pour une raison quelconque
ALORS
La POO est utile.
Personnellement, je m'efforce de trouver des solutions universelles. Cela nécessite de "scinder" des fonctions similaires en un seul bloc sans augmenter la taille du code. Cela augmente l'efficacité du mécanisme et il n'y a pas besoin de surcharge et de division. Il suffit d'utiliser un peu son cerveau et c'est tout).
C'est-à-dire qu'il y avait deux fonctions de 20 lignes chacune. Tous deux effectuent des actions similaires ou résolvent des tâches similaires. Mon objectif est de créer une fonction de 20 lignes de code maximum qui effectue le travail des deux fonctions. C'est ainsi que les blocs apparaissent.
PS.
Il y avait une rubrique pour les perles.
C'est dedans.
Un manuel de programme n'est pas une documentation.
Un manuel est une description de la fonctionnalité d'un programme (ce que le programme peut faire). Il est nécessaire pour l'utilisateur.
La documentation est une description de la structure du programme (comment le programme est construit). Il est nécessaire pour le programmeur.
Il n'y a pas de conflit de termes.
...
Si ce n'est pas le cas, il ne sert à rien de vous encombrer d'informations qui n'ont rien à voir avec le commerce, et il vaut mieux consacrer votre temps à la recherche et au développement.
Bonne chance à vous tous !
Démontrez dans les échanges l'efficacité de R- vous y avez consacré suffisamment de temps. Participer à des concours - 1.septembre ; 2.trimestres
https://www.mql5.com/ru/forum/212596
1. Dans quelle mesure la rentabilité de vos EA a-t-elle augmenté grâce à l'utilisation des OOP?
2. De combien le MTBF de votre EA a-t-il diminué ?
2. Quelle poisse))))) le MTBF d'un programme informatique... clinique !