Frais généraux de l'OLP - page 6

 
Maxim Kuznetsov:

mais cela ne fonctionne pas :-)

Je vous le dis, essayez de le faire, c'est un sacré paquet de code. La classe instanciable "CFoo : public InterfaceCFoo" doit contenir le champ *privateContext d'InterfaceCFoo (faire une relation 1:1), le créer et le supprimer via la fabrique, déléguer toutes les méthodes et traduire les références CFoo* this<->privateContext ici et là. Il s'agit de "coucher le soleil à la main", c'est-à-dire de remplacer l'héritage par la délégation, et ce sur place.

Créez par l'intermédiaire de l'usine et supprimez de la manière habituelle. La nécessité de déléguer dépend de la manière dont le contenu de la bibliothèque est censé être utilisé : si elle fournit des classes qui font le travail par elles-mêmes, il n'est pas nécessaire de déléguer quoi que ce soit - il suffit d'appeler les méthodes de l'interface.

A propos, dans Android/Java, il y a une chose similaire avec les classes de noyau - en raison de l'absence d'héritage multiple, on doit insérer un délégué dans l'objet et créer des méthodes de wrapper pour ses méthodes. C'est la vie.

 
Maxim Kuznetsov:

Je vous le dis, essayez-le, c'est un sacré paquet de code. La classe instanciable "CFoo : public InterfaceCFoo" doit contenir le champ *privateContext d'InterfaceCFoo (faire une relation 1:1), le créer et le supprimer via la fabrique, déléguer toutes les méthodes et en même temps traduire les références CFoo* this<->privateContext ici et là. Il s'agit de "coucher le soleil à la main", c'est-à-dire de remplacer l'héritage par la délégation, et ce sur place.

Et que dire du langage, une personne sobre ne peut comprendre ce qu'ils veulent dire sans un demi-litre. :) Et tous ces trucs de POO et toute cette alphabétisation chinoise sont faits pour - faire un simple échange de données, qui est trivialement réalisé au niveau procédural....
 
Andrei:
Et la langue, une personne sobre ne peut pas comprendre ce dont on parle sans un demi-litre. :) Et tous ces trucs de POO et toute cette alphabétisation chinoise sont faits pour - faire un simple échange de données, qui est trivialement réalisé au niveau procédural....

La POO elle-même n'est pas à blâmer pour l'existence de codeurs vicieux de la POO. Il n'y a rien de mal avec la POO en général, vous avez complètement tort dans votre opinion de la POO.

 
Dmitry Fedoseev:

La POO elle-même n'est pas à blâmer pour l'existence de codeurs vicieux de la POO. Il n'y a rien de mal avec la POO en général, vous avez complètement tort dans votre opinion de la POO.

Vous ne connaissez pas son histoire.

Interdictions répétées pour sabotage direct. Alors ne réagissez pas à son ignorance belliqueuse.

 
Dmitry Fedoseev:

En général, il n'y a rien de mal à la POO ; votre opinion sur la POO est totalement erronée.

Je vais vous donner quelques citations critiques célèbres du wiki à propos de la POO, de la part de personnes qui, pour une raison quelconque, ne sont pas traitées d'ignorantes :

  • Alexander Stepanov a souligné dans l'une de ses interviews que la POO est "méthodologiquement fausse" et que "...la POO est presque autant un canular que l'intelligence artificielle..."[20].
  • Niklaus Wirth estime que la POO n'est rien de plus qu'une superstructure triviale par rapport à la programmation structurelle, et que l'exagération de son importance, qui se traduit, entre autres, par l'inclusion dans les langages de programmation de moyens "orientés objet" de plus en plus à la mode, nuit à la qualité des logiciels développés.
  • Patrick Killelia, dans son livre "Tuning the Web Server", a écrit : "...la POO vous donne de nombreuses façons de ralentir vos programmes...".
 
Andrei:

Pour me libérer, je vais citer quelques citations critiques célèbres du wiki à propos de la POO, de la part de personnes qui, pour une raison quelconque, ne sont pas traitées d'ignorantes :

  • Alexander Stepanov a souligné dans l'une de ses interviews que la POO est "méthodologiquement fausse" et que "...la POO est presque autant un canular que l'intelligence artificielle..."[20].
  • Niklaus Wirth estime que la POO n'est rien de plus qu'une superstructure triviale par rapport à la programmation structurelle, et que l'exagération de son importance, qui se traduit, entre autres, par l'inclusion dans les langages de programmation de moyens "orientés objet" de plus en plus à la mode, nuit à la qualité des logiciels développés.
  • Patrick Killelia, dans son livre "Tuning the Web Server", a écrit : "...la POO vous donne de nombreuses façons de ralentir vos programmes...".

Et tous les trois : Stepanov né en 1950, Wirth en 1934 et le non moins ancien Killea (son livre a été publié en 1998) auront bien honte de le répéter en 2017.

Ce qu'ils ont dit remonte à si longtemps que c'est déjà embarrassant de s'en souvenir. Les compilateurs C++ étaient au moins deux ordres de grandeur plus bêtes et plus primitifs dans les optimisations. En fait, il n'y avait pas la moindre trace d'optimisation. À l'époque (tout début des années 90), j'écrivais moi-même beaucoup d'assembleur et je pensais comme lui : "C/C++ est lent".

Ce n'est pas à moi d'établir des liens sous forme de citations piquées. De plus, vous avez déjà réussi à montrer votre extrême fadeur et votre ignorance agressive dans ce fil.

 

Renat Fatkhullin:

D'autant plus que vous avez déjà réussi dans ce fil à montrer votre extrême fadeur et votre ignorance agressive.

Résumons. Voici ma principale hypothèse sur la POO : "La POO n'a de sens qu'en tant qu'enveloppe de texte pratique ou lorsqu'elle est utilisée de manière minimale pendant l'initialisation de l'exécution..." dans le post #10.

Et voici l'avis motivé d'un expert indépendant avec un avis similaire et des preuves détaillées au niveau du code.

http://rainman-rocks.livejournal.com/122876.html

"La conclusion finale de tout ceci est la suivante :

La principale raison de l'efficacité de la programmation orientée objet est qu'elle contient les moyens de fournir la modularité et la déclarativité. Ce sont la modularité et la déclarativité qui sont les outils qui augmentent l'efficacité du développement - c'est-à-dire des "balles d'argent". Ce sont ces éléments qui doivent être pris en compte lors du choix d'une méthodologie. La POO seule ne devrait pas être l'objectif."

 
Andrei:

Pour résumer. Voici mon hypothèse de base sur la POO : "La POO n'a de sens que comme enveloppe de texte pratique ou lorsqu'elle est utilisée de façon minimale dans l'initialisation de l'exécution..." dans le post #10.

Et voici l'avis motivé d'un expert indépendant avec un avis similaire et des preuves détaillées au niveau du code.

http://rainman-rocks.livejournal.com/122876.html

"La conclusion finale de tout ceci est la suivante :

La principale raison de l'efficacité de la programmation orientée objet est qu'elle contient les moyens de fournir la modularité et la déclarativité. Ce sont la modularité et la déclarativité qui sont les outils qui augmentent l'efficacité du développement - c'est-à-dire des "balles d'argent". Ce sont ces éléments qui doivent être pris en compte lors du choix d'une méthodologie. La POO en elle-même ne devrait pas être l'objectif."

Montrez les projets que vous avez personnellement mis en œuvre afin que votre opinion soit acceptée au moins un minimum. Vous ne pouvez même pas comprendre le lien cité - c'est juste une ode à la POO, y compris la sortie.

Tous les logiciels sont pratiquement écrits à plus de 90% selon la POO (ne dites pas de bêtises sur les pilotes). En fait, il est impossible d'écrire puis de maintenir un grand projet sans POO. Et on n'accepte pas les mots "juste un emballage" lorsqu'il s'agit d'affaires. Le développement de logiciels est depuis longtemps une activité bien établie et éprouvée.

Ceux qui se plaignent de la POO sans la comprendre ne sont pas conscients de ce que font les compilateurs C++ modernes. Il n'y a souvent plus rien du tout de la POO dans le code final. Je parle de C++, bien sûr.

 
Renat Fatkhullin:

Montrez vos projets réalisés personnellement afin que votre opinion soit acceptée au moins un minimum. Vous ne pouvez même pas comprendre le lien cité - c'est juste une ode à la POO, y compris la conclusion.

Permettez-moi de vous citer encore une fois l'idée principale de cet article afin qu'il n'y ait aucun doute sur ce qu'il dit :

"Ainsi, la POO, tout en cherchant à remplacer la programmation structurée-procédurale, a fini par revenir presque à la même chose, mais seulement dans des enveloppes fantaisistes. On peut se demander si la manœuvre avait un sens...".

Désolé, mais je ne comprends pas la logique et la relation de cause à effet - pourquoi avons-nous besoin de projets réalisés pour que l'opinion de chacun soit prise en compte de manière minimale. Habituellement, dans une discussion civilisée, le raisonnement et la validité raisonnable de l'opinion elle-même sont suffisants.

Sinon, nous arrivons à la conclusion absurde que si une personne a mis en œuvre un projet, alors toutes ses déclarations ultérieures doivent être acceptées par tout le monde au départ, alors qu'en fait, elles peuvent ne pas être toutes conformes au raisonnement ou même contredire l'avis d'autres professionnels qui ont également mis en œuvre des projets.

Encore une fois, il n'est pas très modeste de se vanter de quelque chose, car cela est mauvais pour le karma.

 

C'est-à-dire qu'il n'y a pas de projets, donc pas d'expérience.

En même temps, vous n'oubliez pas l'expérience, en essayant de ressortir les plus vieux dictons de personnes autrefois expérimentées(par rapport à leur époque). Comme vous n'avez pas votre propre expérience, vous ne comprenez pas que les énoncés retirés n'ont pas fonctionné il y a longtemps. Ils n'ont pas fonctionné et n'étaient que des illusions propres à cette époque. Ces délires sont déjà embarrassants à rappeler.

En outre, vous ne comprenez pas vraiment l'essence de ce qui est écrit dans les liens cités. Vous arrachez des mots et les interprétez mal, bien qu'il soit dit "la POO est meilleure que les béquilles (et les béquilles sont une tentative d'émuler la POO sans la POO) et doit être utilisée".