Mon approche. Le noyau est le moteur. - page 138
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
"Développer le potentiel créatif des supporters de l'OOP", Vereshchagin, Toile, Huile
Merci à tous pour ces messages informatifs.
Aujourd'hui nous allons tester la communication entre l'EA et le moteur via les ressources. Je viens de le terminer. Cela devrait aussi fonctionner dans le testeur.
Vous travaillez avec la classe CCanvas. C'est le seul dans votre développement.
La classe fait partie du système. Si c'est UN, il n'y a pas de système.
Alors pourquoi créer des objets de classe et se référer à ses fonctions par des règles de POO ?
Vous n'avez PRACTIQUEMENT pas besoin d'OOP pour traiter une seule classe.
Mais, vous utilisez la POO en traitant avec UNE classe. Mais vous n'avez pas besoin de la méthode OOP.
Peter, dans la POO, les objets de classe sont créés pour que vous puissiez travailler avec de nombreux objets qui ne dépendent pas les uns des autres. Lorsque vous travaillez avec CCanvas et que vous avez un seul graphique, tout va bien, la POO n'est vraiment pas nécessaire ici. Mais lorsque vous avez besoin d'afficher plusieurs graphiques dans des zones différentes, il est difficile de le faire sans recourir à la POO et en créant plusieurs instances de CCanvas.
Ou un autre exemple. Récemment, on m'a demandé de modifier un conseiller expert procédural afin qu'il puisse négocier sur différents symboles simultanément (sur un seul graphique). Le style procédural aurait nécessité des efforts longs et complexes pour qu'il se négocie indépendamment sur différents symboles en même temps. En revanche, j'ai simplement placé l'ensemble du code procédural dans une classe et créé trois exemples. J'ai spécifié un ensemble de paramètres individuels pour chacun d'eux, y compris le symbole de travail, etc. Le code a fonctionné correctement du premier coup. Le code a fonctionné comme il aurait dû le faire du premier coup. L'utilisateur était satisfait.
Même vous utilisez la POO dans votre noyau. Bien que vous le fassiez implicitement :
Pour ne pas rester sans réponse, permettez-moi enfin de vous donner un exemple de ce même "noyau". Plus précisément, il s'agit d'un fichier de démarrage. Il y a plusieurs noyaux dedans.
Je vous rappelle qu'il est imprimé automatiquement, sur la base du code KIB. Puis placé dans le moteur. Ensuite, le moteur travaille avec lui.
Chacun de vos noyaux est une instance d'une classe en termes de POO. Quel que soit le nom que vous lui donnez, c'est un élément de la POO. Mais malheureusement, cet élément est autodidacte et inférieur en puissance conceptuelle à ce qui a déjà été inventé et poli par des milliers d'esprits non formés.
Quoi, vous tous, vous convainquez Peter des avantages de la POO ?
Vous ne le convaincrez pas ! Si vous aviez une mémoire comme la sienne, vous vous demanderiez pourquoi tous ces trucs OOP sont si compliqués alors que vous pouvez tout faire beaucoup plus simplement ? Nous rendons toutes les variables globales, un accès direct de partout, pas d'interdictions et de restrictions - sympa !
C'est pour ceux qui, dans leur faible esprit, peuvent oublier ce qu'ils ont écrit il y a dix ans - il est nécessaire que le compilateur et le langage le limitent en tout point. Et lorsque vous vous rappelez exactement pourquoi et pourquoi vous avez écrit telle ou telle construction dans votre code, qui date de plusieurs années - la POO n'est que la cinquième roue du chariot.
Le problème de Peter n'est pas dans le choix "approche OOP ou procédurale", le problème de Peter est dans le public cible. Le manque de personnes qui, d'une part, sont bonnes en programmation et, d'autre part, préfèrent échanger leurs mains. Je n'observe pas de telles personnes.
1. Exactement. Un nombre limité d'éléments peut être prescrit dans le constructeur. Par conséquent, un tableau dynamique doit être composé d'un nombre limité de lignes, mais en même temps, il ne doit pas être limité. La solution consiste uniquement à créer des tableaux spéciaux pour les paramètres ajoutés et à faire défiler leurs valeurs dans les cellules du tableau.
2. Oui. Le constructeur crée un noyau pour le moteur basé sur le code que vous avez cité. + imprime les fichiers de connexion. Ensuite, j'ai mis le noyau dans le moteur (DRIVE). Après cela, le moteur peut jouer l'interface graphique désirée. Les fichiers d'appariement sont connectés à l'EA et commencent à interagir avec elle.
Il s'avère qu'à chaque fois qu'il y a une nouvelle interface graphique, il faut apporter des modifications au moteur (lui fournir le noyau d'interface graphique approprié). Je pense que c'est une solution fondamentalement mauvaise. Imaginez qu'il y ait des centaines d'utilisateurs de votre moteur. Mais le moteur hébergé sur le marché ou ailleurs n'en est qu'un. Comment allez-vous faire dans ce cas ? Pour que chaque utilisateur puisse placer un moteur spécifique, qu'il doit télécharger pour lui-même ? Comment préparez-vous le noyau du gui pour le moteur ? Allez-vous fournir à chaque utilisateur un moteur individuel ? - Cela va rapidement devenir un cauchemar. Votre solution n'est donc pas évolutive.
Peter, dans la POO, les objets de classe sont créés pour que vous puissiez travailler avec plusieurs objets qui ne dépendent pas les uns des autres. Lorsque vous travaillez avec CCanvas et que vous avez un seul graphique, tout va bien, vous n'avez pas vraiment besoin de la POO ici. Mais lorsque vous avez besoin d'afficher plusieurs graphiques dans des zones différentes, il est difficile de le faire sans recourir à la POO et en créant plusieurs instances de CCanvas.
Ou un autre exemple. Récemment, on m'a demandé de modifier un conseiller expert procédural afin qu'il puisse négocier sur différents symboles simultanément (sur un seul graphique). Le style procédural aurait nécessité des efforts longs et complexes pour qu'il se négocie indépendamment sur différents symboles en même temps. En revanche, j'ai simplement placé l'ensemble du code procédural dans une classe et créé trois exemples. J'ai spécifié un ensemble de paramètres individuels pour chacun d'eux, y compris le symbole de travail, etc. Le code a fonctionné correctement du premier coup. Le code a fonctionné comme il aurait dû le faire du premier coup. L'utilisateur était satisfait.
Même vous utilisez la POO dans votre noyau. Bien que vous le fassiez implicitement :
Chacun de vos noyaux est une instance d'une classe en termes de POO. Et quel que soit le nom qu'on lui donne, c'est un élément de la POO. Mais malheureusement, cet élément est autodidacte et cède dans sa puissance conceptuelle à ce qui a déjà été inventé et peaufiné par des milliers d'esprits non expérimentés.
Vasily, je comprends pourquoi les fonctions de dessin sont transformées en une classe. Parce qu'il existe d'autres ensembles de fonctions qu'eux.
Mais ma question était un peu différente. Pourquoi, exactement, Nikolaï utiliserait-il l'appel des fonctions de dessin par une classe, s'il n'utilisait aucune autre classe. Il ne fait que dessiner.
Le but de la question était exactement ça.
J'ai souligné l'inutilité de cette action en termes de logique, et le fait qu'il n'en est pas conscient.
J'ai également souligné que l'utilisation de la POO est souvent déraisonnable par la taille des tâches à résoudre. Après tout, la POO nécessite une classification ramifiée, et si une telle classification n'existe pas, cela vaut-il la peine de la créer exprès ?
L'idée est que le développeur doit être guidé par les exigences des mécanismes, et non des outils.
Peter, dans la POO, les objets de classe sont créés pour que vous puissiez travailler avec plusieurs objets qui ne dépendent pas les uns des autres. Lorsque vous travaillez avec CCanvas et que vous avez un seul graphique, tout va bien, vous n'avez pas vraiment besoin de la POO ici. Mais lorsque vous avez besoin d'afficher plusieurs graphiques dans des zones différentes, il est difficile de le faire sans recourir à la POO et en créant plusieurs instances de CCanvas.
Ou un autre exemple. Récemment, on m'a demandé de modifier un conseiller expert procédural afin qu'il puisse négocier sur différents symboles simultanément (sur un seul graphique). Le style procédural aurait nécessité des efforts longs et complexes pour qu'il se négocie indépendamment sur différents symboles en même temps. En revanche, j'ai simplement placé l'ensemble du code procédural dans une classe et créé trois exemples. J'ai spécifié un ensemble de paramètres individuels pour chacun d'eux, y compris le symbole de travail, etc. Le code a fonctionné correctement du premier coup. Le code a fonctionné comme il aurait dû le faire du premier coup. L'utilisateur était satisfait.
Même vous utilisez la POO dans votre noyau. Bien que vous le fassiez implicitement :
Chacun de vos noyaux est une instance d'une classe en termes de POO. Et quel que soit le nom qu'on lui donne, c'est un élément de la POO. Mais malheureusement, cet élément est autodidacte et cède dans sa puissance conceptuelle à ce qui a déjà été inventé et poli par des milliers d'esprits incompétents.
Vous perdez votre temps. D'abord, votre exemple avec le conseiller de Perth est un cataplasme - il ne sait pas écrire les experts, il ne comprend pas ce qu'il y a là et à quoi ça sert, et il ne comprend pas votre exemple très clair - vous verrez, lui, en battant des yeux, vous dira la même chose qu'à Nikolay. Deuxièmement, vous lui donnerez une excuse pour pousser son nez encore plus haut, en disant qu'il a fait un code super unique dans son seau par lui-même, sans l'aide de milliers d'esprits précédents, avec une solution exceptionnelle meilleure que toute solution précédente. Vous verrez - c'est exactement comme ça qu'il va positionner son seau unique avec des curseurs...
ZS. J'ai peut-être parlé durement, mais j'ai très peu de tolérance pour la stupidité impénétrable.
Chacun de vos noyaux est une instance d'une classe en termes de POO. Et peu importe comment vous l'appelez, c'est un élément de la POO. Mais malheureusement, cet élément est autodidacte et cède dans sa puissance conceptuelle à ce qui a déjà été inventé et poli par des milliers d'esprits incompétents.
C'est ainsi. Mais il y a quand même une différence significative. En ce qui me concerne, chez Peter - dans cet exemplaire de classe - presque tout est disponible. Et cela ne correspond pas au paradigme d'encapsulation de la POO. De plus, il existe des variables globales.
Donc ici - seulement les "éléments de la POO".
Mais, j'ai peur que les gens n'aiment pas l'inverse - je suis sûr, Vasily, que lorsque je lancerai mon projet de POO, au contraire, les gens crieront que "vous ne pouvez rien faire avec cette interface, sauf ce à quoi elle est destinée" :)
Il s'avère qu'à chaque fois que vous créez une nouvelle interface graphique, vous devez apporter des modifications au moteur (l'équiper du noyau d'interface graphique approprié). Je pense que c'est une solution fondamentalement mauvaise. Imaginez qu'il y ait des centaines d'utilisateurs de votre moteur. Mais le moteur hébergé sur le marché ou ailleurs n'en est qu'un. Comment allez-vous faire dans ce cas ? Pour que chaque utilisateur puisse placer un moteur spécifique, qu'il doit télécharger pour lui-même ? Comment préparez-vous le noyau du gui pour le moteur ? Allez-vous fournir à chaque utilisateur un moteur individuel ? - Cela va rapidement devenir un cauchemar. Votre solution n'est donc pas évolutive.
Non, Vasily, tu as tendance à tout dramatiser.)
Il y a un bouton dans le concepteur, qui, lorsqu'on le clique, imprime tous les fichiers.
Et le moteur chargera les noyaux à partir d'un fichier texte. Ce n'est pas difficile à faire.
Peter, vous avez vraiment mal compris quelque chose sur l'application de la POO.
C'est une forme spéciale de conscience, ne l'empêchez pas d'évoluer.