Réaliser un projet de crowdsourcing sur Canvas - page 24
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 deux programmeurs ayant la même expérience et la même intelligence sont en concurrence, ils créent degrands projets similaires. Mais le premier n'utilise que des fonctions, et le second des fonctions et des classes. Définitivement, la victoire sera pour le deuxième. Mais, je le répète, s'il s'agit d'un projet volumineux, ce dernier le rendra plus rapide car il y aura moins de bugs et plus d'ordre. Et le produit de la seconde sera plus lisible, plus facile à entretenir et plus aisément mis à jour et complété. Ce n'est même pas mon avis, c'est juste une déclaration de fait. Il est plus facile de creuser un trou avec une pelle qu'avec une truelle. Si vous implémentiez votre mécanisme non seulement sur les fonctions mais aussi sur les classes, il deviendrait plus efficace. C'est mon avis.
Commençons par la question de la nécessité des classes dans la mise en œuvre de grands mécanismes. Une classe est une coquille pour un ensemble de certaines fonctions, et un "grand mécanisme" est un bloc de code qui met en œuvre un ensemble de tâches. Dans ma mise en œuvre, un "grand mécanisme" est presque toujours une très grande fonction et un ensemble de petites fonctions qui la servent. Le soi-disant "moteur". Si vous le bourrez de fonctions de service dans une seule classe, rien ne changera, et si vous le bourrez dans différentes classes, l'accès entre elles deviendra plus compliqué et l'efficacité du mécanisme diminuera.
Si la taille du mécanisme s'accroît, vous devez optimiser son code ou diviser la fonctionnalité en fichiers. Ce n'est pas suffisant ? De plus, l'optimisation périodique du code en un seul bloc conduit à des miracles d'efficacité. Il est constamment compressé et nécessite de plus en plus de fonctions pour être mis en œuvre. C'est-à-dire que le nombre de fonctions diminue au contraire. Ils sont généralisés en un seul bloc, dont le code est constamment amélioré. C'est une voie directe vers l'efficacité .
De plus, si nous rendons les variables importantes globales, elles seront visibles partout dans le mécanisme, et il sera facile de travailler avec elles, et si nous définissons des scopes pour elles, cela créera une tâche superflue du point de vue de l'efficacité du mécanisme. Encore une fois, la complication de l'accès. Création d'objets de classe, et ainsi de suite... La tendance à fragmenter le mécanisme en un grand nombre de fonctions ruine non seulement l'efficacité, mais aussi l'universalité des blocs de code. Il s'avère que chaque tâche concrète nécessite une fonction distincte, et l'universalité des blocs de code n'est tout simplement pas améliorée. Le nombre d'appels et de paramètres passés augmente également. Cela ne contribue pas à l'efficacité du mécanisme, mais cette tendance est en fait encouragée par la POO.
La POO est plus efficace lorsqu'un projet est géré par une équipe de programmeurs. Dans ce cas, vous ne pouvez pas vous en passer. Bien que, si vous y réfléchissez, vous pouvez trouver un moyen de vous en passer ici aussi...
Mais bien sûr, ce ne sont que des mots. Dans la pratique, je prouverais rapidement ce dont je parle.
Nikolai Semko:
Et, Peter, j'ai jeté un coup d'œil rapide à votre code et je me suis rendu compte que vous utilisez pleinement le canvas (bien que ce ne soit pas la classe CCanvas, mais qui s'en soucie). Alors pourquoi toutes ces questions sur la toile et pourquoi j'essaie d'expliquer toutes ces choses ici ? :)).
)))), je suis un peu surpris par tes explications sur les principes de dessin de kanvas. Je t'ai déjà dit et montré que tout ce qui est dans mon kanvas est dessiné.)) (Enfin presque tout. :))
J'ai commencé ce sujet parce que je ne comprends pas pourquoi jusqu'à présent personne n'a pas dessiné le même bouton que le mien. Après tout, et selon vos mots, c'est facile.
))), j'ai aussi été un peu surpris par votre explication des principes du dessin sur toile, car je vous ai déjà dit et montré que tout est dessiné.))) (Enfin presque tout. :))
J'ai commencé ce sujet parce que je ne comprends pas pourquoi jusqu'à présent personne n'a pas dessiné le même bouton que le mien. Après tout, et selon vos mots, c'est facile.
Si vous n'avez pas vu, cela ne signifie pas que personne d'autre que vous ne peut le faire. C'est juste tellement insignifiant que vous n'avez même pas besoin de le poster - un événement trop insignifiant - créer juste un bouton - pour poster son code, pas parce que vous êtes le meilleur ;)
Vous êtes tous en compétition, et à juste titre, Anatoly - avec des moulins à vent.
Si vous ne l'avez pas vu, cela ne veut pas dire que personne d'autre que vous n'est capable de le faire. C'est juste tellement insignifiant qu'il n'y a pas besoin de le poster - un événement trop insignifiant - juste la création d'un bouton - pour poster son code, pas parce que vous êtes le meilleur ;)
Vous êtes tous en compétition, et à juste titre, Anatoly - avec des moulins à vent.
Calme-toi, Artem. J'ai déjà compris que vous ne m'aimez pas. Apparemment, c'est le cas de beaucoup d'autres personnes sur cette ressource. C'est peut-être justifié, mais c'est trop de changer de personnalité à l'improviste quand on discute de questions techniques.
Je suis calme, qu'est-ce qui te fait penser le contraire ?
Aimez/n'aimez pas une personne - ce n'est pas un forum technique pour discuter. Vous êtes neutre pour moi, rien de plus. De même, comme pour le reste d'entre nous, il me semble.
Mais pour qu'on ne vous mentionne pas dans le style "ah-ah-ah..., c'est ce Don Quichotte..., je me souviens, je me souviens...", il faut que vous fassiez au moins quelque chose d'utile.
Vous pouvez faire ou ne pas faire ce que vous voulez - c'est votre droit, et personne ne le conteste. Personne n'a besoin de votre parole ici - vous devriez vous la donner en premier lieu ;)
L'atmosphère est très amicale - les gens vous disent combien il est agréable d'utiliser la POO dans certaines situations, un homme crucifie devant vous, essayant de vous aider dans quelque chose, codant pour vous montrer, pour que ce soit plus compréhensible. Mais il s'avère - d'après vos propres mots - que vous n'en avez même pas besoin - vous ne savez simplement pas avec qui d'autre rivaliser, et essayez de défier les gens "faiblement".
Et ce qui me semble aussi - vous n'êtes pas parce que vous avez décidé de ne pas écrire et de ne pas étudier la POO, que vous avez tout pesé et compris que vous, en utilisant la programmation procédurale, écrivez un code bien meilleur et optimisé (comme vous l'avez présenté à tout le monde ici), mais simplement parce que vous n'y comprenez rien, et avez inventé une excuse, que vous avez annoncée à tout le monde, en la soutenant avec des mots et un défi "ne croyez que celui qui me bat".
Vous vous souvenez de la blague sur "Elusive Joe" ?
...
Vous vous souvenez de la blague sur "Elusive Joe" ?
Tout à fait d'accord.
L'insaisissable lyriciste/philosophe... :-) les mêmes conneries que "Joe", mais dans "l'autre main"... :-)
Commençons par la question de la nécessité des classes dans la mise en œuvre de grands mécanismes. Une classe est une coquille pour un ensemble de fonctions, et un "grand mécanisme" est un bloc de code qui met en œuvre un ensemble de tâches. Dans ma mise en œuvre, une "grande machine" est presque toujours une très grande fonction et un ensemble de petites fonctions qui la servent. Le soi-disant "moteur". Si vous le bourrez de fonctions de service dans une seule classe, rien ne changera, et si vous le bourrez dans différentes classes, l'accès entre elles deviendra plus compliqué et l'efficacité du mécanisme diminuera.
Si la taille du mécanisme s'accroît, vous devez optimiser son code ou diviser la fonctionnalité en fichiers. Ce n'est pas suffisant ? De plus, l'optimisation périodique du code en un seul bloc conduit à des miracles d'efficacité. Il est constamment compressé et nécessite de plus en plus de fonctions pour être mis en œuvre. C'est-à-dire que le nombre de fonctions diminue au contraire. Ils sont généralisés en un seul bloc, dont le code est constamment amélioré. C'est une voie directe vers l'efficacité .
De plus, si nous rendons les variables importantes globales, elles seront visibles partout dans le mécanisme, et il sera facile de travailler avec elles, et si nous définissons des scopes pour elles, cela créera une tâche superflue du point de vue de l'efficacité du mécanisme. Encore une fois, la complication de l'accès. Création d'objets de classe, et ainsi de suite... La tendance à fragmenter le mécanisme en un grand nombre de fonctions ruine non seulement l'efficacité, mais aussi l'universalité des blocs de code. Il s'avère que chaque tâche concrète nécessite une fonction distincte, et l'universalité des blocs de code n'est tout simplement pas améliorée. Le nombre d'appels et de paramètres passés augmente également. Cela ne contribue pas à l'efficacité du mécanisme, mais cette tendance est en fait encouragée par la POO.
La POO est plus efficace lorsqu'un projet est géré par une équipe de programmeurs. Dans ce cas, vous ne pouvez pas vous en passer. Bien que, si on y réfléchit, on peut trouver un moyen de l'éviter ici aussi...
Mais bien sûr, ce ne sont que des mots. Dans la pratique, je prouverais rapidement ce dont je parle.
Peter, c'est juste que j'avais l'habitude de programmer uniquement avec des fonctions et que je raisonnais presque de la même manière que toi maintenant, et puis j'ai presque par force (car la force de l'habitude est incroyable) commencé à programmer avec des classes. Maintenant, je peux comparer les deux états, alors que vous, qui n'avez pas essayé d'appliquer les cours, ne le pouvez pas. Sans vouloir vous offenser. Ça me rappelle juste une autre situation. Je suis végétarien depuis de nombreuses années maintenant. Et avec une régularité enviable, il y a des gens qui n'ont jamais été végétariens et qui essaient de me bassiner avec les protéines, les acides aminés essentiels, etc. Je leur dis : nous ne sommes pas dans des conditions égales, j'étais un mangeur de viande et maintenant je suis végétarien donc je peux comparer ces deux conditions en termes de pratique. Vous ne l'êtes pas et vos connaissances ne sont que théoriques et n'ont rien à voir avec la pratique.
Ne perdez pas votre temps - maîtrisez la POO.
Tu es complètement banni de ce forum, mon ami. :)) Moi y compris. :( Ne désespérez pas - ce qui ne nous tue pas nous rend plus fort. Je crois en vous ! !! :))
Ne perdez pas votre temps - maîtrisez la POO.
Tu es complètement banni de ce forum, mon ami. :)) Moi aussi. Ne désespérez pas - ce qui ne nous tue pas nous rend plus fort. Je crois en vous !!! :))
Commençons par la question de la nécessité des classes dans la mise en œuvre de grands mécanismes. Une classe est une coquille pour un ensemble de fonctions, et un "grand mécanisme" est un bloc de code qui met en œuvre un ensemble de tâches. Dans ma mise en œuvre, une "grande machine" est presque toujours une très grande fonction et un ensemble de petites fonctions qui la servent. Le soi-disant "moteur". Si vous le bourrez de fonctions de service dans une seule classe, rien ne changera, et si vous le bourrez dans différentes classes, l'accès entre elles deviendra plus compliqué et l'efficacité du mécanisme diminuera.
Si la taille du mécanisme augmente, il est nécessaire d'optimiser son code ou de diviser la fonctionnalité en fichiers. Ce n'est pas suffisant ? De plus, l'optimisation périodique du code en un seul bloc conduit à des miracles d'efficacité. Il est constamment compressé et nécessite de plus en plus de fonctions pour être mis en œuvre. C'est-à-dire que le nombre de fonctions diminue au contraire. Ils sont généralisés en un seul bloc, dont le code est constamment amélioré. C'est une voie directe vers l'efficacité .
De plus, si nous rendons les variables importantes globales, elles seront visibles partout dans le mécanisme, et il sera facile de travailler avec elles, et si nous définissons des scopes pour elles, cela créera une tâche superflue du point de vue de l'efficacité du mécanisme. Encore une fois, la complication de l'accès. Création d'objets de classe, et ainsi de suite... La tendance à fragmenter le mécanisme en un grand nombre de fonctions ruine non seulement l'efficacité, mais aussi l'universalité des blocs de code. Il s'avère que chaque tâche concrète nécessite une fonction distincte, et l'universalité des blocs de code n'est tout simplement pas améliorée. Le nombre d'appels et de paramètres passés augmente également. Cela ne contribue pas à l'efficacité du mécanisme, mais cette tendance est en fait encouragée par la POO.
La POO est plus efficace lorsqu'un projet est travaillé par un groupe de programmeurs. Dans ce cas, vous ne pouvez pas vous en passer. Bien que, si on y réfléchit, on peut trouver un moyen de l'éviter ici aussi...
Mais bien sûr, ce ne sont que des mots. Dans la pratique, je prouverais rapidement ce dont je parle.
Et il y a quelque chose à cela. Alan Kay, le créateur de la POO, avait en fait une idée très différente de ce que l'on entend par POO aujourd'hui. Elle est encore plus proche de votre vision. J'ai l'idée de créer un projet avec un noyau et des services faisant appel à lui pour certaines fonctionnalités. Et la communication entre les éléments se fera uniquement par le biais d'événements-messages. Dès que vous envoyez une demande d'événement avec les données, vous recevez une réponse d'événement avec le résultat. Il n'y a pas d'héritage, de polymorphisme ou d'inclusion.
À propos, avec cette approche, le multithreading est plus facile à organiser car, par définition, tous les éléments fonctionnent indépendamment les uns des autres.
Il y a quelque chose là-dedans. Alan Kay, le créateur de la POO, avait une idée différente de ce que l'on entend par POO aujourd'hui. Elle est encore plus proche de votre vision. J'ai l'idée de créer un projet avec un noyau et des services faisant appel à lui pour certaines fonctionnalités. Et la communication entre les éléments se fera uniquement par le biais d'événements-messages. Dès que vous envoyez une demande d'événement avec les données, vous recevez une réponse d'événement avec le résultat. Il n'y a pas d'héritage, de polymorphisme ou d'inclusion.
D'ailleurs, avec cette approche, le multithreading est plus facile à organiser, car tous les éléments travaillent par définition indépendamment les uns des autres.