Mon approche. Le noyau est le moteur. - page 16
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
Pour l'instant, j'ai un seul client. J'accomplis ses tâches très rapidement. 3-4 heures et une nouvelle fenêtre, entièrement fonctionnelle, est prête. Avec l'interface de connexion. Je corrige aussi rapidement les bugs dans le moteur et lui envoie les nouvelles versions. 9 fenêtres en quelques jours + changements de moteur, correction de bugs, ajout de fonctionnalités... Tout est très rapide.
Vous devez avoir beaucoup de temps libre.
Vous comprenez que vous n'êtes pas suffisant. La massivité de votre moteur dépendra de son appréciation par d'autres programmeurs (vous seul ne suffisez pas à tous les clients). Et si les progermes n'aiment pas ça, alors... hélas, le sort de votre création sera glorieux.
Les programmeurs n'auront pas à entrer dans le code du moteur. Ils obtiendront l'interface de connexion à celle-ci dans le dossier. Je l'ai déjà testé. Tout fonctionne.
Pour l'instant, j'ai un seul client. J'accomplis ses tâches très rapidement. 3-4 heures et une nouvelle fenêtre, entièrement fonctionnelle, est prête. Avec l'interface de connexion. Je corrige aussi rapidement les bugs dans le moteur et lui envoie les nouvelles versions. 9 fenêtres en quelques jours + changements de moteur, correction de bugs, ajout de fonctionnalités... Tout est très rapide.
Est-ce que c'est bien dit ? 3-4 heures pour créer une fenêtre ? Pas des minutes ?
En fait, je le fais depuis plus d'un an maintenant. Et je ne m'embrouille pas.))
À titre de comparaison, implémentez la même chose en utilisant la POO. Peut-être que vous l'aimerez. :)
Est-ce que c'est bien dit ? 3-4 heures pour créer une fenêtre ? Pas des minutes ?
Non. Vous pouvez le faire en quelques minutes si vous copiez le code d'une autre fenêtre et faites des modifications. Mais je parlais de le créer à partir de zéro, en pensant aux graphiques et en travaillant sur le style.
Au fait, Peter, n'oublie pas d'ajouter toutes sortes de graphiques, comme des indicateurs, uniquement dans Windows, avec le support de quelques formats de données (OHLC, comme Zigzag, etc.). J'espère que tout cela est facilement réalisable dans votre projet.
Je vais essayer.
Je vais essayer.
Je n'essaierai pas, je le ferai). Augmente l'utilité de votre création.
Est-ce que c'est bien dit ? 3-4 heures pour créer une fenêtre ? pas des minutes ?
Quelle absurdité... faire 3 fenêtres dans MQL même en utilisant les bibliothèques de la boîte à outils MT standard prend 10 minutes et 20-30 minutes de plus pour adapter la hauteur et le XY des boutons, des éditions, des étiquettes...
Je vois deux possibilités pour lesquelles le travail de Petr peut être utile :
- création d'une application séparée pour générer le code source MQL, c'est-à-dire le constructeur GUI et ne pas entrer dans les détails de son fonctionnement, c'est-à-dire Visual MQL++ ;)))
- Ou encore : il y a des gens qui créent leurs propres difficultés et les surmontent avec succès © Wingston Churchill
Il me semble que tous les composants OOP de Peter s'accrochent constamment à des détails.
Et le cœur du problème est précisément la philosophie et l'architecture du système.
Il a été dit à juste titre ci-dessus quelles sont les questions controversées, qui semblent être des avantages pour Pierre et des inconvénients pour ses adversaires :
- un tas de variables accessibles à tous, sans aucune encapsulation.
- l'absence de contrôle du type
- une dépendance rigide à l'égard d'une mise en œuvre particulière du stockage des données.
Et Peter a correctement dit que le concept de POO (au moins dans mes suggestions) est conçu pour simplifier, "sur la base de la commodité du programmeur". Encapsulation, contrôle des types, interfaces - tout ceci est conçu pour éliminer autant que possible la possibilité même d'erreur, de confusion, de mauvaise utilisation. C'est vrai.
Le concept de Pierre est à l'opposé. Toutes les données sont accessibles de n'importe où, l'utilisateur de n'importe quel endroit du code a un contrôle total sur tous les objets du programme et il peut les percevoir comme il le souhaite sans aucune restriction de type (enfin, sauf pour les restrictions de MQL).
Selon Peter, ce concept "permet d'atteindre un développement maximal". La convivialité vient en second lieu".
Personnellement, en tant que programmeur, je n'aime déjà pas que la commodité passe au second plan. Mais vous pouvez sacrifier cela si vous obtenez un développement beaucoup plus important. Eh bien, je veux voir ce que c'est. Là où l'approche OOP avec ses restrictions et son encapsulation ne permet pas d'atteindre un tel développement, comme cette approche avec un accès complet à l'énorme éventail de propriétés, jeté dans un tableau de tailles monstrueuses. (Sans parler de la nécessité de se souvenir de tout).
Comme il a été souligné à juste titre ci-dessus, cette approche rappelle la TurboVision de Pascal. Bien que le contrôle des types et les contraintes d'encapsulation aient déjà été mis en œuvre dans cette bibliothèque.