Mon approche. Le noyau est le moteur. - page 135
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 y a un autre problème. La limitation des éléments et paramètres de base. Je sais quelle devrait être la solution. Je n'ai juste pas encore eu l'occasion de le faire.
C'est pourquoi je demande. Si vous avez 21 cordes cousues dans le noyau, ce n'est pas très bon et vous ne pouvez pas le réparer.
Non. C'est du code externe qui est écrit pour le constructeur. Cela reproduit le tableau. Ensuite, je clique sur le bouton et tous les fichiers de connexion et le noyau d'amorçage pour le moteur sont imprimés. Ensuite, tout fonctionne.
Si j'ai bien compris, il s'agit d'un autogénérateur qui génère le code d'autoconnexion et une partie du code du noyau. Une solution intéressante.
Je ne l'ai pas encore testé.
Ça marche pour moi. Mais il semble y avoir un problème avec la fermeture d'une ligne lorsqu'un stop est déclenché. Parfois, la rangée reste. Il s'agit d'un problème de détection des ordres fermés dans le code que j'ai écrit. La table n'a rien à voir avec cela.
1. C'est pour ça que je demande. Si vous avez 21 lignes dans le noyau, ce n'est pas bon et vous ne pouvez pas simplement le réparer.
2. Je comprends que c'est un autogénérateur qui génère le code d'autoconnexion et une partie du code du noyau. Une solution intéressante.
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, être illimité. La solution consiste simplement à 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'interface se connectent à l'EA et commencent à interagir avec elle.
Pour ne pas rester sans réponse, je vais enfin vous donner un exemple du "noyau" lui-même. Plus précisément, il s'agit d'un fichier de démarrage. Il existe plusieurs noyaux.
Je vous rappelle qu'il est imprimé automatiquement, sur la base du code KIB. Puis placé dans le moteur. De plus, le moteur fonctionne avec lui.
Nikolay, parlons du sujet. Prenez la classe CCanvas, par exemple, dont j'ai déjà parlé. Donc, j'ai enlevé toutes les fonctions de celui-ci. Les rendre indépendants de l'enveloppe de la classe. En quoi est-ce pire maintenant ? Il est devenu plus facile de travailler avec eux. J'ai réalisé une animation en utilisant ces fonctions. Avant cela, je n'ai pratiquement jamais vu d'animations avec cette classe.
Alors pourquoi cet emballage ?
Vous dessinez aussi sur une toile. Vous pourriez simplement appeler une fonction spécifique et dessiner. Mais non. Vous emballez et emballez et emballez. Alors explique-moi, pourquoi ?
Oui, parce que c'est méga-confortable. Mais c'est très difficile à comprendre jusqu'à ce qu'on commence à l'utiliser soi-même.
Je ne suis pas capable de penser d'une manière qui me convienne. Par conséquent, ce n'est pas pratique pour moi. Enrouler, représenter l'orientation de l'objet. Classer quand c'est nécessaire et quand ce n'est pas nécessaire...
On a l'impression que la POO elle-même prend le pas sur le mécanisme qu'elle est censée servir. En d'autres termes, le mécanisme doit viser l'intégrité, donc le plus petit nombre de ses blocs. Mais la POO oblige ces blocs à se multiplier pour n'importe quelle raison. En conséquence, la structure des mécanismes est en lambeaux et ils ne fonctionnent pas bien. Et ils se développent encore plus.
Nikolay, commencez à créer des méga-mécanismes (10 fois plus grands que la classe Kanvas), et vous comprendrez où et comment la POO devient gênante.
Je ne sais pas comment penser d'une manière qui me mette à l'aise. Par conséquent, pour moi, c'est inconfortable. Enveloppe, représentation de l'orientation de l'objet. Classer quand c'est nécessaire et quand ce n'est pas nécessaire...
On a l'impression que la POO elle-même prend le pas sur le mécanisme qu'elle est censée servir. En d'autres termes, le mécanisme doit viser l'intégrité, donc le plus petit nombre de ses blocs. Mais la POO oblige ces blocs à se multiplier pour n'importe quelle raison. En conséquence, la structure des mécanismes est en lambeaux et ils ne fonctionnent pas bien. Et ils se développent encore plus mal.
Nikolay, commencez à créer des méga-mécanismes (10 fois plus grands que la classe Kanvas), et vous comprendrez où et comment la POO devient gênante.
Vos paroles ne disent qu'une chose :
...
Nikolaï, ne t'est-il jamais venu à l'esprit que ton amour pour la POO n'est pas justifié par presque rien d'autre que des raisons abstraites ?
Par exemple, si vous créez des mécanismes gigantesques avec cette POO, vous comprendrez pourquoi vous en avez tant besoin. Vous devez justifier spécifiquement pourquoi vous avez besoin de la POO. Mais, vous créez des mécanismes relativement petits. Il n'y a pas assez de code pour tirer des conclusions sur les inconvénients et les avantages de telle ou telle approche. Mais vous continuez à parler d'OOP de toute façon. Alors que la POO n'est qu'un outil, et n'a aucun sens en soi. C'est-à-dire que s'il n'y a pas de mécanisme à réaliser, la POO n'est pas nécessaire. Mais s'il existe un mécanisme, il devrait être suffisamment sérieux pour nécessiter la POO lors de sa création.
La plupart de ceux qui défendent OOP ne font rien de sérieux. Ils ne font que des petites choses. Cependant, leur croyance dans la POO est inébranlable. D'autres qui fabriquent des mécanismes beaucoup plus sérieux sont beaucoup moins susceptibles de crier à la grandeur de la POO. Certains s'expriment même par des critiques (il y en a eu quelques unes).
Votre argument doit donc être étayé par la pratique, et pas seulement par la théorie. Je peux, par exemple, discuter des avantages de la POO dans le développement d'interfaces graphiques avec Anatoly, car nous pouvons comparer les solutions et leurs nuances dans la pratique. Mais, avec vous, je ne peux pas déployer mon argumentation car vous ne la comprendrez pas. Vous le ferez, mais vous ne le comprendrez pas (sans vouloir vous offenser). Anatoly, au contraire, peut très bien le comprendre. La différence d'expérience en matière de création de mécanismes mondiaux est la principale raison du malentendu.
SZY. En tant que praticien, je vous dirai ceci : l 'approche doit être telle qu'elle maximise le potentiel des cerveaux d'un programmeur particulier. J'ai trouvé une telle approche pour moi-même.