Mon approche. Le noyau est le moteur. - page 18
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
Non, pendant que nous discutons de la programmation occasionnelle, je traîne la couverture vers la POO, le lanceur du sujet s'accroche toujours ! Il écrit que tout peut être gardé dans sa tête - et bien, la programmation occasionnelle)))).
Moteur de base
Programmation occasionnelle ;))
Programmation occasionnelle :)
Programmation occasionnelle :)
Vous avez peut-être raison, je me souviens de ce terme - il y a quelques mois, sur un autre forum, un type se qualifiait de programmeur occasionnel, j'ai même essayé de préciser ce que cela pouvait signifier, ma connaissance du mot occasionnel n'est associée qu'au jeu Android - "Zuma", il s'est avéré que c'est un programmeur qui programme au hasard - de temps en temps ))))
La POO est une méthodologie très flexible, elle n'a donc pas d'idées a priori comme le concept de "noyau". Cependant, le modèle de noyau en question ici peut très bien être construit en utilisant la POO. Par conséquent, l'affirmation n'est pas entièrement correcte.
Non, OOP n'a rien à voir avec ça du tout. Le noyau est Unix, nous assemblons tout autour du noyau ; le shell est tout ce qui ressemble à Windows, nous enlevons le superflu et travaillons avec le reste. En général, il s'agit d'un système d'exploitation.
Programmation cajun :)
Cajual, ne vous inquiétez pas.
Ce qui me répugne dans la POO, c'est le format rigide d'écriture du code. Comme vous l'avez vu, j'ai tendance à faire de grands tableaux de données et je trouve cela très pratique. Dans la POO, je dois adhérer à un tas de règles, que je trouve personnellement très contraignantes.
En bref, je programme avec une POO différente. Le mien. Il y a peu de règles et beaucoup de liberté. La fonctionnalité elle-même est empilée en grands blocs, et les données sont organisées en noyaux. Je ne réfléchis même pas spécialement à leur structure. Tout se développe par lui-même. Au niveau intuitif.Peter, ces règles sont celles dont tu as besoin toi-même. C'est pour ça qu'ils vous "raidissent". Pour que tu ne fasses pas accidentellement une erreur et que tu ne te retrouves pas dans quelque chose que tu n'es pas censé faire. En fait, le style POO est un "code de la route" - bien sûr, il limite le conducteur. Et dans un village avec trois cours - personne ne les regarde, c'est plus facile et plus rapide (plus efficace). Cependant, dans une grande ville, c'est le contraire - ce sont les règles de circulation qui permettent les liaisons de transport les plus efficaces. C'est la même chose avec l'AOP. Ce sont les règles qui vous permettent de construire de grands systèmes complexes de la manière la plus efficace possible.
Dans votre système, il n'y a pas encore eu de changement, son utilisation est très limitée et il n'est pas nécessaire de le modifier. C'est pourquoi tu peux le garder dans ta tête. Ce n'est pas grave si le système reçoit des utilisateurs et nécessite des modifications - le manque de contrôle et d'encapsulation sera assez stressant.
Tout le reste - aucune différence, la POO et votre style (comme il a été dit, vous avez aussi un style procédural - qui souffre des mêmes défauts - variables globales, manque de contrôle des types, etc.
Pour défendre votre style, vous devez prouver une seule chose : que garder l'ensemble du système dans un énorme tableau global avec un accès arbitraire est mieux que de décomposer le programme en un tas de petites parties imbriquées dans des chaînes d'héritage avec un accès polymorphe, et cachées par l'encapsulation.
Au fait, il y a des gens sur le forum qui n'aiment pas l'héritage - je pense qu'ils pourraient vous soutenir.
Un autre avantage de l'utilisation de la POO, par opposition à la méthode de Peter. En POO, le programmeur n'a pas besoin du code source de la classe de base et n'a pas besoin de comprendre son fonctionnement. Pour étendre ou modifier la fonctionnalité de la classe de base, il suffit de créer un héritier de cette classe.
Si vous utilisez la méthode de Peter, le programmeur doit comprendre tout le long code, et s'il n'y a pas de code source, vous devrez l'écrire à partir de zéro.
Tout le reste - aucune différence, la POO et votre style (comme déjà mentionné, vous avez un style procédural - qui souffre également des mêmes inconvénients - variables globales, manque de contrôle des types, etc.) sont autrement proches.
je peux me tromper, et googler est trop paresseux, mais le style procédural implique une complétude logique d'une procédure (fonction) - la "dévisser" de la source et l'utiliser dans un autre code, c'est-à-dire que les fonctions MQL intégrées prennent des données comme paramètres et renvoient le résultat..... et ici, Piotr est tombé sur ses deux pieds )))) - L'échange par le biais de variables déclarées globalement réduit la portabilité du code et permet des bogues difficiles à repérer ;)
Très bien. Disons que je suis convaincu.
En principe, je comprends tout cela depuis longtemps. Et je suis d'accord avec ça. Cependant, en même temps, je préfère ma propre approche. Pourquoi ?
Il y a une raison particulière :
LE DÉVELOPPEMENT DU PROGRAMME.
//---------------------------------------
À quelle vitesse le programme se développera-t-il avec la POO et avec mon approche ? Quelle approche est plus favorable à la croissance et à la complication des mécanismes ?
J'ai conclu que mon approche + la langue maternelle dans le code (60% de russe et 40% d'anglais), donnent une croissance rapide maximale du programme.
C'est précisément de cette croissance rapide dont j'ai besoin. Je ne creuse pas dans les détails. Pas seulement en survolant chaque ligne de code. Ce n'est pas une approche professionnelle.
Je voulais que le programme se développe rapidement et devienne plus complexe. Que des mécanismes seraient créés pour remplir les fonctions qui leur sont attribuées. Rapide et facile.
Pour que vous puissiez ajouter de nouvelles fonctionnalités avec quelques lignes de code.
Mon approche est supérieure à la POO pour résoudre cette tâche particulière.