Une question pour les experts de la POO. - page 11
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
Si un programmeur entre dans le monde du forex, il n'est pas nécessaire d'être un professionnel et de connaître la POO.
Il est préférable d'apprendre les subtilités du marché et de développer une stratégie de trading rentable. Et cela n'a pas d'importance si vous utilisez la POO ou non. La rentabilité du conseiller expert n'en souffrira pas.
Vous n'avez pas à gaspiller votre énergie.
George, ce n'est pas seulement une question de mémoire. J'ai créé un environnement de développement confortable pour moi, en utilisant ma langue maternelle ainsi que l'anglais. Le code bilingue est beaucoup mieux mémorisé que le code monolingue. Surtout lorsque vous n'êtes pas bloqué par des mots standard et que vous pouvez appeler les variables par le nom que vous voulez. Prouvé. J'ai simplement ignoré le professionnalisme en matière de programmation et j'ai commencé à écrire comme bon me semblait. En conséquence, j'ai commencé à naviguer rapidement dans mon code et à le lire, le mémoriser et le développer facilement. Le reste, vous le savez...
Je ne pense pas que ça puisse aider. Pour moi, les noms des variables dans n'importe quel langage sont effacés de ma mémoire presque instantanément, je me lève de derrière mon ordinateur et je ne me souviens déjà que des principes généraux et je ne peux pas dire quelles variables ont été entrées à quel endroit.
D'ailleurs, c'est la raison pour laquelle j'utilise toujours des paires de fichiers mqh-mq5 au lieu d'écrire les classes entièrement dans des fichiers mqh - j'ai besoin de regarder souvent les fichiers d'en-tête, juste pour me rappeler ce qui est disponible dans tel ou tel cas, j'ai les fichiers mqh d'en-tête nécessaires ouverts dans des onglets et je passe à eux, quand j'ai besoin de rafraîchir ces informations à nouveau. Lorsque toute une classe (et encore plus plusieurs classes) est décrite dans un seul fichier mqh, il est plus difficile de "sauter" dans ce fichier, même avec l'aide des onglets.
Je ne peux pas garder toute la structure dans ma mémoire, bien que dans ma jeunesse, comme je l'ai déjà mentionné, j'ai même écrit en assembleur, mais il n'y a pas d'autres options - vous n'avez que les adresses de la mémoire, et le maximum que permet l'assembleur macro est de créer des noms de zones spécifiques en utilisant des macrosubstitutions. Mais j'ai depuis longtemps acquis la conviction que de cette manière, le nombre d'erreurs est beaucoup plus important et le débogage d'un tel code est beaucoup plus difficile.
J'ai déjà donné un exemple ci-dessus : une erreur se produit et une variable est modifiée de manière incorrecte pour une raison quelconque. Et on accède à cette variable depuis de nombreux endroits du programme. Comment attraper un endroit où il y a une erreur ? Avec l'encapsulation OOP, c'est très simple - nous mettons un point d'arrêt dans la fonction d'interface qui modifie la variable, et dès qu'une modification incorrecte se produit - nous nous arrêtons et voyons immédiatement, par la hiérarchie d'appel, où la modification incorrecte a été faite.Et avec votre approche, Peter, nous devons fouiller dans tout le code, en cherchant tous les endroits où cette variable est accédée, en mettant des points d'arrêt partout, et en analysant tous les appels, pas seulement les appels incorrects.
C'est ça le truc, il peut souffrir. Un de mes amis a perdu une partie de son dépôt à cause d'une erreur dans son code alors que la POO rend les erreurs moins probables.
Cela signifie qu'il n'est pas un bon programmeur. Vous pouvez être plus confus dans les constructions complexes de la POO que sans elle.
Les classes doivent être appliquées là où elles sont nécessaires. J'ai remarqué que certains programmeurs ont l'obsession d'appliquer de nombreuses fonctions là où elles ne sont pas nécessaires. Il en va de même pour les cours.
Au lieu d'écrire un programme compact et court sans POO, certains programmeurs commencent à appliquer des classes, de nombreuses fonctions et une solution simple se transforme en un texte d'un kilomètre de long.
Cela signifie qu'il n'est pas un bon programmeur. Vous pouvez être plus confus dans les constructions complexes de la POO que sans elle.
Toutes choses étant égales par ailleurs ? J'en doute fort. Si la complexité des constructions est la même, il est beaucoup plus facile de leur donner un sens avec la POO.
Cependant, cela n'annule pas la règle "d'un canon sur un moineau", cela n'a aucun sens d'utiliser de grandes complexités OOP là où la tâche est très simple et compacte.
Bien que, comme cela a déjà été dit ici - la POO nous permet de construire des bibliothèques de classes, qui sont ensuite utilisées dans de nombreux projets.
Disons, les mêmes classes de tableaux, de fichiers... Même lorsque vous écrivez un indicateur très simple, sans utiliser la POO, il est beaucoup plus facile de déclarer une classe CFile et d'utiliser ses fonctions, plutôt que d'utiliser les fonctions standard de travail avec les fichiers.Sans parler de la possibilité de remplacer facilement CFile par d'autres plus spécifiques, par exemple, j'ai une classe CLogFile avec la possibilité d'insérer automatiquement l'heure et quelques données supplémentaires dans les chaînes (pour les fichiers journaux) ou la classe CIniFile, qui peut organiser les données dans des fichiers ini standard, puis les lire et les utiliser lorsque cela est nécessaire.
Cela signifie qu'il n'est pas un bon programmeur. Vous pouvez être plus confus dans les constructions complexes de la POO que sans elle.
Les classes doivent être appliquées là où elles sont nécessaires. J'ai remarqué que certains programmeurs ont l'obsession d'appliquer de nombreuses fonctions là où elles ne sont pas nécessaires. Il en va de même pour les cours.
Au lieu d'écrire un programme compact et court sans POO, certains programmeurs commencent à appliquer des classes, de nombreuses fonctions et une solution simple se transforme en un texte d'un kilomètre de long.
Est-il acceptable que le travail réel ne représente qu'une centaine de lignes, et que les quelques milliers restants soient une bibliothèque écrite et déboguée il y a longtemps ? )))
Si un programmeur utilise des classes toutes faites dans son programme, comme celles-ci : CTrade, CAccountInfo, CPositionInfo, cela ne signifie pas que son programme est basé sur la POO.
Tout dépend si le programmeur crée lui-même de telles classes, ou s'il les utilise simplement sans connaître les éléments internes (au niveau du texte source) de ces classes.
....
Un exemple a déjà été donné ci-dessus - une erreur s'est produite, pour une raison quelconque, une variable a été incorrectement modifiée. Et on accède à cette variable à partir d'un tas d'endroits dans le programme. Comment attraper un lieu où l'erreur ? Avec l'encapsulation OOP, c'est très simple - nous mettons un point d'arrêt dans la fonction d'interface qui modifie la variable, et dès qu'une modification incorrecte se produit - nous nous arrêtons et voyons immédiatement, par la hiérarchie d'appel, où la modification incorrecte a été faite.Et avec votre approche, Peter, nous devons fouiller dans tout le code, en cherchant tous les endroits où la référence à cette variable se produit, en mettant des points d'arrêt partout, et en analysant tous les appels, pas seulement les appels incorrects.
Oui, mon noyau est modifié dans toutes les parties du programme et des erreurs se produisent, mais je n'ai pas besoin de points d'arrêt. Je calcule dans mon esprit et j'alerte à plusieurs endroits pour vérifier les valeurs. C'est comme ça que je le trouve. J'insiste - je connais très bien mon programme.
Mais, du côté positif, avec ces connaissances, aucun obstacle syntaxique et une langue maternelle, j'ai d'énormes possibilités de développement rapide. Et c'est pourquoi je suis contre la POO dans mes solutions.
Le fractionnement du code, sa monolingualité étrangère, une nouvelle syntaxe, des règles supplémentaires - tout cela va ralentir le développement du programme. Je vais perdre plus d'efforts et obtenir moins de résultats. Je le sais de source sûre.
Si ma tâche consistait à construire et à déboguer un programme à partir de morceaux de code prêts à l'emploi, seules la POO et les bibliothèques feraient l'affaire. Accrocher et développer de nouvelles solutions sont des choses différentes. De nombreuses personnes préconisent la POO parce qu'elles veulent utiliser des morceaux de code d'autres personnes et économiser des efforts. Je crée mes propres solutions en utilisant une technologie propriétaire et j'ai des besoins et des points de vue différents sur la POO.
Oui, mon noyau est modifié dans toutes les parties du programme et des erreurs se produisent, mais je n'ai pas besoin de points d'arrêt. Je calcule dans mon esprit et j'alerte à plusieurs endroits pour vérifier les valeurs. C'est comme ça que je le trouve. J'insiste - je connais très bien mon programme.
Mais le côté positif est qu'avec de telles connaissances, l'absence d'obstacles syntaxiques et la langue maternelle, j'ai d'énormes possibilités de développement rapide. Et c'est pourquoi je suis contre la POO dans mes solutions.
Le fractionnement du code, sa monolingualité étrangère, une nouvelle syntaxe, des règles supplémentaires - tout cela va ralentir le développement du programme. Je vais perdre plus d'efforts et obtenir moins de résultats. Je le sais de source sûre.
Si ma tâche consistait à construire et à déboguer un programme à partir de morceaux de code prêts à l'emploi, seules la POO et les bibliothèques feraient l'affaire. Accrocher et développer de nouvelles solutions sont des choses différentes. De nombreuses personnes préconisent la POO parce qu'elles veulent utiliser des morceaux de code d'autres personnes et économiser des efforts. Je crée mes propres solutions en utilisant une technologie propriétaire et j'ai des besoins et des points de vue différents sur la POO.
Je conseille d'utiliser au moins une fois le modèle de boîte de dialogue VC++, de créer une application basée sur le CDialog de MFC, d'y placer toutes sortes de contrôles en mode visuel, d'utiliser des fonctions prêtes à l'emploi pour comprendre toute la puissance de la POO.
Et j'aimerais également ajouter que Borland C++ dispose de classes très pratiques pour travailler avec Oracle. J'ai travaillé avec elle jusqu'en 2012, je ne sais pas comment maintenant.
Je conseille d'utiliser au moins une fois le modèle de boîte de dialogue VC++, de créer une application basée sur le CDialog de MFC, d'y placer toutes sortes de contrôles en mode visuel, d'utiliser des fonctions prêtes à l'emploi, pour comprendre toute la puissance de la POO.
Et j'aimerais également ajouter que Borland C++ dispose de classes très pratiques pour travailler avec Oracle. J'ai travaillé avec elle jusqu'en 2012, je ne sais pas comment maintenant.
c'est le deuxième semestre de 2019.... mais le 20 et le 25 et .... Se disputeront-ils aussi sur la nécessité d'utiliser la POO?
))))
si nous l'aimons, nous l'utilisons, si nous ne l'aimons pas, nous ne l'utilisons pas.
si vous avez pris l'habitude d'écrire des programmes en utilisant des petits sous-programmes écrits précédemment - écrivez, vous vous êtes levé du mauvais côté du lit... vous mettez tous ces sous-programmes dans le code source et vous obtenez un grand désordre de code.
donner aux gens beaucoup de possibilités de l'open source, ce n'est toujours pas la même chose, réduire la fonctionnalité au pur C, encore une fois ce n'est pas la même chose ))))
ZS : Je soupçonne que certains des développeurs lisent le forum de toute façon... Je pense que ce fil de discussion va certainement leur remonter le moral ! ))))