Questions sur la POO (programmation orientée objet) - page 2
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
Comme toujours, j'ai voulu apprendre, mais il y a forcément ceux qui n'ont rien d'autre à dire que de faire les malins...
J'ai écrit un exemple simple pour le démonter, je ne sais pas comment écrire de manière plus compétente avec la POO ... C'est juste un exemple, si vous savez comment écrire un code similaire correctement et OOP alors s'il vous plaît écrivez, afin que moi et d'autres puissent apprendre ...
La POO commence par la recherche d'un objet. S'il n'y a pas d'objet, il n'y a pas de POE.
En général, un objet est constitué de ressources, de données.
Il suffit d'écrire et de regarder comment les autres écrivent. Ensuite, vous le découvrirez par vous-même. Vous pouvez également lire des manuels scolaires. Il y en a beaucoup sur l'Internet.
La POO commence par la recherche d'un objet. S'il n'y a pas d'objet, il n'y a pas de POE.
En général, un objet est constitué de ressources, de données.
Il suffit d'écrire et de regarder comment les autres écrivent. Ensuite, vous le découvrirez par vous-même. Vous pouvez également lire des manuels scolaires. Il y en a beaucoup sur l'Internet.
Recommandez-nous quelques manuels, s'il vous plaît ... Le plus facile et le plus utile à votre avis ...
Recommander un ou deux tutoriels s'il vous plaît ... Le plus facile et le plus utile à votre avis ...
Grady Buch. "Object-Oriented Analysis and Design". Avec des exemples d'applications C++".
Ire Paul (parfois orthographié Ira Paul) "Programmation orientée objet en C++".
1) Pas lié à la POO, mais il faudrait ajouter un gestionnaire d'erreur pour les opérations commerciales(OrderSend(), OrderDelete(), OrderModify( ))...
Pour le rendre pertinent pour la POO - le faire comme une méthode de classe virtuelle (pour le surcharger dans les classes descendantes, ajoutant le traitement d'autres codes).
2) Toutes les méthodes de classe qui, dans les classes descendantes, peuvent fonctionner différemment de maintenant - rendez-lesvirtuelles.
Le premier candidat est openorders().
L'inconvénient est que dans les méthodes virtuelles, vous ne pouvez pas modifier le nombre et le type de paramètres.
En revanche, les "anciens" Buy, Sel, BuyStop , etc. pourront appeler la "nouvelle" (modifiée dans la classe enfant) openorders().
3) Ayons des noms plus jolis d'un coup. OpenOrders au lieu de openorders, par exemple.
4) Si la terminologie consiste à appeler quelque chose, alors vous devez utiliser une terminologie similaire.
Si vendre = VENDRE, alors vous l'appelez VENDRE ou VENDRE (c'est-à-dire SellStop au lieu de SelStop).
5) Vous devez supprimer toutes les constantes (500, etc.) de la classe.
Qu'ils soient pris dans des variables ou définis comme paramètres de méthodes.
Vous vous souvenez maintenant d'environ 500 éléments intégrés dans openorders(), mais plus tard vous oublierez tout cela ou vous écrirez beaucoup de chouettes utilisant ces classes et il sera difficile de changer quelque chose.
Les erreurs architecturales sont les plus difficiles à corriger.
Et c'est le squelette que vous êtes en train de créer (si ce n'est pas un simple exercice).
6) Ne mettez pas tout dans une seule classe.
Créez une classe clOrder et collez-y SetSL, CloseOrder, GetSL, GetProfit, SetTP, GetTP , etc.
Et dans la classe clTrade , ajoutez un tableau/une liste d'ordres, un symbole et les propriétés du symbole(TICKETSIZE, POINT, TICKETVALUE, MINLOT, MAXLOT, STOPSTEP, LOTSTEP, LOTSIZE , etc.)
Si vous attachez Ask et Bid (comme propriétés d'un symbole), n'oubliez pas de les rafraîchir dans OnTick().
Pour RefreshRates(), faites un binding pour qu'après la mise à jour des variables МТ les propriétés Ask et Bid soient appelées (j'ai aussi vérifié le statut des ordres, qui a ouvert et qui a fermé. Ceux qui sont fermés sont retirés de la liste des commandes).
Vous pouvez ajouter le calendrier (tout d'abord, créez une classe) et le trailing stop (créez également une classe séparée).
PS : J'ai fait tout cela le week-end (j'ai fait une bibliothèque pour les métiers), mais cette fois j'ai décidé de ne pas utiliser de classes (seulement des structures, des tableaux de structures et des fonctions qui fonctionnent avec tout cela).
Il y a aussi un horaire pour chaque jour (puisque Alps on gold a une pause tous les jours de 0:00 à 1:00). Au cours des deux dernières minutes de négociation, le contrôleur de calendrier ferme toutes les transactions et annule tous les ordres.
Et au cours de la dernière heure de négociation, il ferme les positions perdantes, annule les ordres et exécute les positions rentables. J'ai également prévu un stop suiveur. Un seul type, mais il s'adapte à différents symboles en raison de différents paramètres.
Le schéma est le suivant : des symboles (avec leurs propres champs), des ordres (avec leurs propres champs), des horaires (avec leurs propres champs) et un conseiller expert avec ses propres champs (magik, etc.) se référant à un symbole et possédant une liste d'ordres et une liste d'horaires.
Le sommet de la hiérarchie est la liste des conseillers (la combinaison symbole+magie doit être unique).
Recommandez des tutoriels s'il vous plaît ... Le plus simple et le plus utile à votre avis ...
Des exemples écrits en utilisant la POO apparaissent maintenant dans CodeBase. De VOLDEMAR, par exemple ))))
En fait, c'est votre site https://www.mql5.com/ru/code/11159 qui m'a inspiré la réécriture de ma bibliothèque commerciale pour les structures.
J'ai décidé d'attendre avec les classes - je ne vois pas l'intérêt de les utiliser dans MQL .
Ou bien est-ce un standard uniquement dans MQL5, qui a été repris dans le nouveau MetaEditor ?
Des exemples écrits en utilisant la POO apparaissent maintenant dans CodeBase. De VOLDEMAR, par exemple ))))
En fait, c'est votre site https://www.mql5.com/ru/code/11159 qui m'a inspiré la réécriture de ma bibliothèque commerciale pour les structures.
J'ai décidé d'attendre avec les classes - je ne vois pas l'intérêt de les utiliser dans MQL jusqu 'à présent.
Oui, j'ai écrit cela, mais à part le transfert des fonctions vers une classe, je n'ai encore rien compris d'autre,
Oui, j'ai écrit cela, mais à part le transfert de fonctions vers une classe, je n'ai encore rien compris d'autre,
3(+1) principes de la POO :
1) Encapsulation. C'est-à-dire le stockage de variables, de pseudo-variables (appelées "propriétés de l'objet" ou simplement "propriétés") dans l'objet lui-même. C'est-à-dire que si une classe est déclarée correctement, ses données ne peuvent pas être modifiées de l'extérieur.
Seulement en utilisant les fonctions de la classe elle-même (appelées "méthodes de classe" ou simplement "méthodes"). Nécessaire non seulement pour attribuer une valeur à une variable, mais aussi pour effectuer une action liée à la modification de ces champs.
Et c'est la principale utilité (à mon avis) de l'introduction de la POO dans MQL, plutôt que le portage de fonctions (les fonctions de ma bibliothèque de commerce reçoivent l'index de l'EA comme l'un des paramètres et travaillent avec l'EA sélectionné, y compris son tableau d'ordres).
Personne ne peut s'introduire dans les données d'une classe créée par vous (s'il n'y a pas de code source) et se plaindre ensuite que votre code comporte des erreurs.
2) L'héritage. Lorsqu'une classe ancêtre est créée, elle hérite de tous les champs et méthodes de la classe ancêtre (il existe un type privé pour les champs et méthodes qui ne peuvent pas être vus dans les classes ancêtres, mais nous l'omettons pour le moment).
Et ici, lors de la phase de conception de l'objet, vous devez clairement penser à l'architecture - comment la classe sera utilisée, quels champs elle contiendra, comment ils doivent être visibles dans les classes descendantes, etc.
Il est utilisé dans des systèmes puissants et des bibliothèques de classes, pour des tâches que je ne vois personnellement pas dans les tâches commerciales. Mais peut-être que quelqu'un en aura besoin. Vous pouvez créer des classes descendantes avec des stops suiveurs différents, par exemple.
C'est pourquoi il n'y a pas de constantes à l'intérieur des méthodes, tout doit être défini en externe via des méthodes appropriées (qui commencent généralement par .Set) ou directement comme paramètres des méthodes. C'est ce que je veux dire à propos de vos 500.
3) Polymorphisme. La chose que j'ai écrite quelques posts plus haut - quand une fonction remodelée dans une classe descendante openorders() appellera librement les anciennes fonctions Buy().
Un exemple de polymorphisme est le calcul de l'aire d'une figure géométrique pour différentes formes.
Il est calculé d'une certaine manière pour un cercle, d'une autre manière pour un carré. Mais dans tous les cas - en appelant Figura.GetSquare() nous obtiendrons l'aire d'une forme particulière héritée d'une classe de base (si nous n'avons pas oublié de déclarer Square() ).
Là encore, une certaine qualification est nécessaire pour créer l'architecture de la classe de base. Par exemple, si vous oubliez de déclarer Square() comme virtuel, il sera impossible d'appeler Square de manière générique (vous devrez vérifier le type de la classe avant chaque appel et appeler son implémentation de Square).
Certains recommandent de rendre virtuelles toutes les méthodes, à l'exception des constructeurs (je suis du même avis si vous ne voyez pas l'horizon de ce que cette classe peut devenir lorsque vous la créez). L'essentiel est que les destructeurs soient également virtuels.
Mise à jour :
================
4) Abstraction (comme demandé par les camarades, bien que lorsque j'ai étudié la POO (dans les années 1990), elle n'était pas considérée comme un principe (car en fait - juste dérivé des trois premiers), et dans l'article (voir lien ci-dessous) il est écrit à ce sujet, mais il n'est pas dans le titre de l'article, il y a seulement 3).
En pratique, cela revient à créer une classe de base "vide" (où les méthodes sont déclarées, mais ne font rien). Dans certains langages, une méthode peut être marquée comme abstraite, ce qui signifie que dans une classe descendante, elle doit nécessairement être superposée (c'est-à-dire qu'une méthode qui fait quelque chose est ajoutée).
===================
PS : vous pouvez lire brièvement, sans entrer dans le vif du sujet, iciPPS : Je ne veux offenser personne, mais lorsque j'ai demandé dans Work d'écrire une bibliothèque commerciale, seule 1 personne a répondu qu'elle l'avait et l'utilisait.
5 programmeurs MQL (sur Skype) ont dit qu'ils n'avaient aucune idée de ce qu'il devrait contenir et qu'ils copiaient-collaient les fonctions requises d'une de leurs chouettes à une autre. Ils collent même RefreshRates() entre des fragments de code qui ne changent rien et ne peuvent être exécutés plus de quelques millisecondes. Et le code suivant ne dépend pas de la modification de l'offre et de la demande et (peut-être) des types d'ordres.
Par conséquent, pour les programmeurs MQL qui n'ont pas travaillé avec la POO dans d'autres langages de programmation auparavant, la POO dans MQL ne sera pas utile. Tout au plus, il cachera les données des changements externes (ce qui n'est pas mal non plus).
3) Les 3 principes de la POO :
1) Encapsulation. C'est-à-dire le stockage de variables, de pseudo-variables (appelées "propriétés de l'objet" ou simplement "propriétés") dans l'objet lui-même. C'est-à-dire que si une classe est déclarée correctement, ses données ne peuvent pas
2) L'héritage. Lorsqu'une classe ancêtre est créée, elle hérite de tous les champs et méthodes de la classe ancêtre (il existe un type privé pour les champs et méthodes qui ne peuvent être vus dans les classes ancêtres, mais nous l'omettons ici pour le moment).
3) Polymorphisme. Ce que j'ai écrit quelques posts plus haut - lorsqu'elle est remodelée dans une classe descendante, la fonction openorders() appellera sans risque les anciennes fonctions Buy( ), etc.
Un exemple de polymorphisme est le calcul de l'aire d'une figure géométrique pour différentes formes.
Il est calculé d'une certaine manière pour un cercle et d'une autre manière pour un carré. Mais dans tous les cas, en appelant Figura.GetSquare() nous obtiendrons l'aire d'une forme particulière héritée de la classe de base (à moins que nous ayons oublié de déclarer Square() ).
Où est le quatrième ? ! Où est le résumé ? Mériteusement oublié :-(
Ajouter.