OOP, templates et macros dans mql5, subtilités et utilisations - page 7
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
À mon avis, ce n'est pas si mal. Il n'y a pas tant d'interfaces de base en C#, à mon avis (je ne suis pas un expert en C#), que leurs méthodes ne peuvent pas être réduites à une superclasse de base, puis héritées par quiconque a besoin de quoi...
Que voulez-vous dire par "hériter de ce dont vous avez besoin" ? hériter non pas de toute la classe mais d'une partie de celle-ci ? ) Je ne suis pas familier avec une telle fonctionnalité.
Non, je voulais dire définir de nombreuses fonctions virtuelles et les surcharger dans les héritages si nécessaire.
Non, je voulais dire définir de nombreuses fonctions virtuelles et les surcharger dans les héritages si nécessaire.
C'est le chaos total et l'incontrôlabilité. Les interfaces définissent des méthodes abstraites qui doivent être implémentées, pas "par nécessité". Cela garantit l'implémentation de ces méthodes au niveau de l'objet. Et avec votre approche, si vous oubliez de surcharger une méthode quelque part, le programme sera compilé comme si rien ne s'était passé mais le programme sera appelé au lieu de la méthode nécessaire.
Pas un blanc, mais une exception "non mise en œuvre". En C#, c'est un peu partout.
... Si vous oubliez de surcharger une méthode quelque part, le programme sera compilé comme si de rien n'était, mais au lieu de la méthode requise, une méthode vide sera appelée. C'est normal...
C'est ainsi que cela fonctionne dans MQL, d'ailleurs ;(.
Pas un blanc, mais une exception "non mise en œuvre". Dans le C# également, il semble que tout soit éparpillé.
C'est ainsi que cela fonctionne dans MQL, d'ailleurs ;(
Ce n'est pas la question. Vous proposez de détecter les bogues au moment de l'exécution, alors que ces bogues peuvent (et devraient) être détectés au moment de la compilation.
Je pense que c'est mieux que de construire des structures comme le modèle <,,,,,,,> pour les classes. Cela vous brisera le cerveau avant que vous n'ayez fini de construire un tel "système de classes".
Je pense que c'est mieux que de construire des structures comme le modèle <,,,,,,,> pour les classes. Cela vous brisera le cerveau avant que vous n'ayez fini de construire un tel "système de classes".
Je préfère me creuser les méninges avec le compilateur, mais je serai sûr que mon programme est garanti de fonctionner correctement et qu'une méthode fonctionnelle est appelée, et non pas quelque chose de fou.
Si l'ensemble a une classe de base simple, qui apparaît partout, et qu'ensuite les casts dynamiques disparaissent, cela peut fonctionner).