Une question pour les experts de la POO. - page 10
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
Et moi aussi - petit à petit... et la compréhension totale ne vient qu'après 4-5 ans (et c'est normal pour une personne ordinaire).
À mon avis, la "pleine compréhension" n'est pas nécessaire. L'essentiel est de "saisir l'essence". Moi, quand je me suis familiarisé avec la méthodologie OOP, c'était en 1995.
J'avais déjà une certaine expérience du "C normal" dans l'esprit de K&R (les oldfags doivent s'en souvenir), en plus d'utiliser assez souvent des fonctions assembleur. Au début, j'étais plutôt sceptique à l'égard des idées de la POO, non pas tant parce que le programmeur devait effectuer des actions supplémentaires, mais à cause de la pure "surcharge" du CPU. Mais j'ai vite été convaincu de l'utilité de cette technologie et laclasse CString a été le principal "interrupteur" dans mon esprit.
En plus de cela, le travail avec les chaînes de caractères était beaucoup plus simple : à l'époque, nous écrivions un packer de données et ma partie était l'analyseur de texte d'entrée. Par conséquent, il est apparu très pratique de créer une hiérarchie de diverses chaînes de caractères sur la base de la classe CString, qui présentait des différences importantes pour notre emballeur.
J'ai particulièrement apprécié le fait qu'après l'écriture du packer de données, la tâche semblait l'utiliser pour des chaînes de caractères, qui contenaient beaucoup d'informations numériques, ce pour quoi le packer n'avait pas été conçu à l'origine. Une classe représentant de telles chaînes avec des chiffres (et aussi un compresseur spécifique pour les chiffres) a été écrite, tout a été ajouté aux classes existantes et l'empaqueteur a commencé à travailler avec de nouvelles données, bien que cette fonctionnalité n'ait pas été prévue initialement.
C'est à ce moment-là que j'ai vraiment apprécié le potentiel de la POO pour modifier et maintenir le code. Bien sûr, il y a une certaine surcharge du processeur, mais elle est plus que compensée par la réduction du travail des programmeurs.
C'est pourquoi je recommande à tous ceux qui commencent à apprendre la POO de commencer par de telles tâches, où l'avantage de la POO serait bien et clairement visible. C'est-à-dire avec les tâches de traitement de différents objets dans des listes, qui représenteraient des instances de classes ayant un ancêtre commun.Ecoutez, j'ai cette chaîne dans mes abonnements, en général j'ai une opinion positive de l'auteur, et il y a même une reprise du sujet de votre vidéo pour lequel la dispute a commencé :
Je suis presque entièrement d'accord avec toutes les idées de la vidéo. Il y a quelques petites objections qui ne sont même pas des objections mais des clarifications (par exemple, je considère que NULL est un pointeur très utile qui indique une erreur, nous devons juste garder à l'esprit que la fonction peut retourner ce pointeur nul, et, clairement, la vidéo dit correctement - il ne peut pas être manipulé comme un objet).
Et tout le reste sur les imprécisions, l'ordre de développement, les getter-setters et le même NULL est correct.
Félicitations à l'auteur.
Il est étrange qu'étant une personne philosophe et bien abstraite, je sois si désespérée de rejeter l'approche de la programmation chère aux professionnels. Alors qu'elle a été conçue pour être pratique, la POO est devenue surchargée d'entités et redondante par rapport à ses tâches. La "redondance" des outils entrave la solution, tout comme la rareté. Et cette redondance est sans doute une conséquence du marketing. En y réfléchissant, une POO minimale suffit à tout résoudre dans le domaine des problèmes informatiques. De même que tout peut être créé avec des fonctions simples et une bonne gestion de la mémoire. Au niveau initial, j'ai tout de suite adopté la POO. Puis j'ai remarqué que certaines entités ne pouvaient pas justifier la nécessité de leur existence et vivaient leur propre vie, abstraite des tâches, à l'intérieur du concept en expansion. Oui, ils sont intégrés dans les solutions, mais ils parasitent l'intelligence des développeurs. Ils ralentissent le processus de travail, réduisant ainsi son efficacité. Ils entravent le flux de travail par l'obscurcissement, la syntaxe, les règles... C'est ce que je n'aime pas dans cette optionalité à l'intérieur de la solution.
Donc, je vais utiliser la POO la plus minimale. Celui qui a été créé avant de le commercialiser.
Il est étrange qu'étant une personne philosophe et bien abstraite, je sois si désespérée de rejeter l'approche de la programmation chère aux professionnels. Alors qu'elle a été conçue pour être pratique, la POO est devenue surchargée d'entités et redondante par rapport à ses tâches. La "redondance" des outils entrave la solution, tout comme la rareté. Et cette redondance est sans doute une conséquence du marketing. En y réfléchissant, une POO minimale suffit à tout résoudre dans le domaine des problèmes informatiques. De même que tout peut être créé avec des fonctions simples et une bonne gestion de la mémoire. Au niveau initial, j'ai tout de suite adopté la POO. Puis j'ai remarqué que certaines entités ne pouvaient pas justifier la nécessité de leur existence et vivaient leur propre vie, abstraite des tâches, à l'intérieur du concept en expansion. Oui, ils sont intégrés dans les solutions, mais ils parasitent l'intelligence des développeurs. Ils ralentissent le processus de travail, réduisant ainsi son efficacité. Ils entravent le flux de travail par l'obscurcissement, la syntaxe, les règles... C'est ce que je n'aime pas dans cette optionalité à l'intérieur de la solution.
Donc, je vais utiliser la POO la plus minimale. Celui qui a été créé avant de le commercialiser.
Oui. Vous créez une classe, par exemple, pour travailler avec un fichier. Vous commencez à l'utiliser et vous avez des bugs. Vous fermez une partie du code et essayez d'en faire quelque chose dans l'autre partie. Il existe deux approches. La première est d'essayer de toujours se souvenir du lieu de fabrication d'un produit, et même avec un seul développeur, cela peut ne pas être très bon. La deuxième - avant l'action de vérifier les opérations à faire. Bon, le bug suivant : dans les opérations de vérification, qui sont éparpillées dans le code, on trouve ici et là des coquilles, un mauvais signe, corrigé à un endroit, oublié à un autre, etc. En conséquence, vous êtes passé d'une efficacité de code si appréciée à une chose triviale et simple : chaque méthode de lecture/écriture et ainsi de suite a un appel à une méthode de vérification avec une option pour annuler cet appel, que vous n'utiliserez presque jamais. Et puis vous vous rendez compte que c'est une bonne chose, car le matériel moderne vous permet de ne pas compter les cycles d'horloge et la consommation de mémoire dans 98 % des tâches résolues.
Oui. Vous créez une classe, par exemple, pour travailler avec un fichier. Vous commencez à l'utiliser et vous avez des bugs. Vous fermez une partie du code et essayez d'en faire quelque chose dans l'autre partie. Il existe deux approches. La première est d'essayer de toujours se souvenir de l'endroit où un produit est fabriqué, et même avec un seul développeur, vous pouvez échouer à le faire.
Peter est bon dans ce domaine.
C'est là le problème - Peter est à l'aise avec l'utilisation d'un énorme tableau de toutes les variables, qui est toujours disponible dans l'ensemble du programme, et dans lequel il prend ce dont il a besoin à tout moment. Pour le titan de la mémorisation, c'est très pratique.
Dans la POO, l'encapsulation est une fonction d'archivage, qui est juste utilisée pour garantir que l'utilisateur, où qu'il soit dans le code, n'a accès qu'aux variables dont il a besoin et à aucune autre variable. Mais pour Peter c'est un moins, il se souvient déjà où, quoi et comment il a utilisé. Il veut pouvoir accéder à n'importe quelle variable dans n'importe quelle partie du programme à tout moment. Il n'aime pas mon approche, lorsque pour accéder à une variable, il faut d'abord obtenir un pointeur vers l'interface, et à partir de l'interface, il faut obtenir la fonction, et seulement ensuite, elle renvoie la valeur dont vous avez besoin. Et à chacune de ces étapes, vous pouvez rencontrer une restriction d'accès. Je pense que c'est une bonne chose, car s'il y a une restriction - elle est mise en place pour une raison, cela signifie que je n'ai pas considéré certains détails importants. Et pour Peter, c'est un obstacle, car il prend toujours tout en compte.
Oui, vous avez créé une classe pour gérer, disons, un fichier. Vous commencez à l'utiliser et vous obtenez des erreurs. Vous fermez une partie du code et essayez d'en faire quelque chose dans l'autre partie. Il existe deux approches. La première est d'essayer de toujours se souvenir du lieu de fabrication d'un produit, et même avec un seul développeur, cela peut ne pas être très bon. La seconde - avant l'action de vérification des opérations à effectuer. Bon, le bug suivant : dans les opérations de vérification, qui sont éparpillées dans le code, on trouve ici et là des coquilles, un mauvais signe, corrigé à un endroit, oublié à un autre, etc. En conséquence, vous êtes passé d'une efficacité de code si appréciée à une chose triviale et simple : chaque méthode de lecture/écriture et ainsi de suite a un appel à une méthode de vérification avec une option pour annuler cet appel, que vous n'utiliserez presque jamais. Et puis vous vous rendez compte que c'est une bonne chose, car le matériel moderne vous permet de ne pas compter les cycles d'horloge et la consommation de mémoire dans 98 % des tâches résolues.
Imaginons la situation inverse. Eh bien, vous n'avez pas d'insectes. Pas du tout et presque jamais, car vous vous souvenez de TOUT et tenez compte de TOUT !Utiliseriez-vous OOP juste à cause de votre "devoir professionnel" ? Je ne pense pas. De quoi vous soucieriez-vous alors ? - Seulement l'efficacité de vos codes. Vous essayerez d'éliminer tous les frais généraux, afin que le code fonctionne aussi rapidement que possible. Vous essayerez également de créer votre code de manière à ce qu'il se développe rapidement.
Lorsque les gens me parlent de bugs qui se produisent ici et là, je les comprends, mais lorsqu'ils sont associés à l'utilisation ou à la non-utilisation de la POO, je ne suis pas d'accord. Le nombre de bogues dépend de la connaissance et de la compréhension que l'on a de son code. Celui qui écrit le code le connaît mieux que celui qui le branche. Celui qui l'écrit a toujours moins de bogues. Comme vous le comprenez, la POO favorise la portabilité du code, dont le revers est une mauvaise compréhension par les autres programmeurs. C'est la source des bugs.
J'écris tout moi-même, et je trouve des bogues dans des blocs de 2000 lignes sans fonctions de profilage et de vérification. Simplement, je connais mon code. Le meilleur remède contre les insectes.))
Ça marche pour Peter.
C'est là le problème - Peter est à l'aise avec un énorme tableau de toutes les variables, qui est toujours disponible dans l'ensemble du programme, et dans lequel il prend ce dont il a besoin à tout moment. Pour le titan de la mémorisation, c'est plutôt pratique.
L'encapsulation dans la POO est une fonctionnalité d'archivage, qui est précisément utilisée pour garantir que l'utilisateur n'a accès qu'aux variables dont il a besoin à n'importe quel endroit du code, et pas plus. Mais pour Peter c'est un moins, il se souvient déjà où, quoi et comment il a utilisé. Il veut pouvoir accéder à n'importe quelle variable dans n'importe quelle partie du programme à tout moment. Il n'aime pas mon approche, lorsque pour accéder à une variable, il faut d'abord obtenir un pointeur vers l'interface, et à partir de l'interface, il faut obtenir la fonction, et seulement ensuite, elle renvoie la valeur dont vous avez besoin. Et à chacune de ces étapes, vous pouvez rencontrer une restriction d'accès. Je pense que c'est une bonne chose, car s'il y a une restriction - elle est mise en place pour une raison, cela signifie que je n'ai pas considéré certains détails importants. Et pour Peter, c'est un obstacle, car il prend toujours tout en compte.
George, ce n'est pas seulement une question de mémoire. J'ai créé un environnement de développement pratique pour moi, en utilisant ma langue maternelle et l'anglais également. Un code bilingue est BEAUCOUP plus facile à retenir qu'un code monolingue. En particulier 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. En outre, vous savez...
ZS. Qu'ils ne pensent pas que je vous incite à vous soucier du professionnalisme. Absolument pas. J'ai craché dessus à cause de mon ego surdimensionné. Il s'avère que cela peut être non seulement mauvais, mais aussi bon. :)
Peter, votre raisonnement suggère que vous n'avez jamais travaillé en équipe. Vous n'avez pas vu comment chacun fait sa part d'une tâche énorme, et comment tout s'assemble à la fin.
Par exemple, sans la POO, il était impossible de créer et de développer Windows.
Si ce n'était pas nécessaire, j'essaierais de ne pas appliquer de classes non plus. Mais lorsque j'ai décidé de transformer mon robot en un robot multi-devises, j'ai immédiatement appliqué des classes, parce qu'il était déjà clair ce qui se passerait sans OOP.
En appliquant des classes, il est évident que les paires d'objets utilisées sont de la même classe et qu'il est déjà très facile de travailler avec elles simultanément.
Peter, votre raisonnement suggère que vous n'avez jamais travaillé en équipe. Vous n'avez pas vu comment chacun fait sa part d'une tâche énorme, et comment tout s'assemble à la fin.
Par exemple, sans la POO, il était impossible de créer et de développer Windows.
Si ce n'était pas nécessaire, j'essaierais de ne pas appliquer de classes non plus. Mais lorsque j'ai décidé de transformer mon robot en un robot multi-devises, j'ai immédiatement appliqué des classes, parce qu'il était déjà clair ce qui se passerait sans OOP.
En appliquant des classes, il est évident que les paires d'objets utilisées sont de la même classe et qu'il est déjà très facile de travailler avec elles simultanément.
Oui, je ne faisais pas partie de l'équipe. Mon approche doit être considérée comme l'expérience d'un seul développeur. Je ne suis pas en train de vous persuader de le suivre. Il y a trop d'impertinence dans mon approche).
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.