Mon approche. Le noyau est le moteur. - page 137

 
Nikolai Semko:
Peter, vous avez vraiment mal compris quelque chose à propos de l'application de la POO.
Désolé, mais ça pue la schizophrénie.

Nikolaï, construisez-vous l'HIERARCHIE ou créez-vous des mécanismes de dessin ?

Si vous construisez une HIERARCHIE (sans vous soucier du dessin), alors il est clair que vous avez besoin de la POO partout.

Si vous créez un mécanisme de dessin qui fonctionne sur la base d'UNE classe, alors vous n'avez pas besoin de la classe elle-même.


Classe, - du mot Classification. La classification est une division par attributs. La classe est un dérivé de la classification. S'il y a une seule classe, alors il n'y a pas de classification.

Donc la classe, dans ce cas, est une connerie abstraite. Ça n'a pas de sens.

 
Ce n'est pas la classe seule, c'est l'implémentation.
 
Реter Konow:

...

On a l'impression que la POO elle-même prend le pas sur le mécanisme qu'elle est censée servir. En d'autres termes, le mécanisme doit viser l'intégrité, donc le plus petit nombre de ses blocs. Mais la POO oblige ces blocs à se multiplier pour n'importe quelle raison. En conséquence, la structure des mécanismes est en lambeaux et ils ne fonctionnent pas bien. Et ils se développent encore plus.

...

Peut-être devriez-vous étudier un peu la POO au lieu de la fantasmer ? Vous ne fantasmez même pas, vous délirez.

 
Реter Konow:

Nikolaï, ne t'est-il jamais venu à l'esprit que ton amour pour la POO n'est pas justifié par presque n'importe quoi mais par des raisons abstraites ?

Par exemple, si vous créez des mécanismes gigantesques avec cette POO, vous comprendrez pourquoi vous en avez tant besoin. Vous devez justifier spécifiquement pourquoi vous avez besoin de la POO. Mais, vous créez des mécanismes relativement petits. Il n'y a pas assez de code pour tirer des conclusions sur les inconvénients et les avantages de telle ou telle approche. Mais vous continuez à parler d'OOP de toute façon. Alors que la POO n'est qu'un outil, et n'a aucun sens en soi. C'est-à-dire que s'il n'y a pas de mécanisme à réaliser, la POO n'est pas nécessaire. Mais s'il existe un mécanisme, il devrait être suffisamment sérieux pour nécessiter la POO lors de sa création.

La plupart de ceux qui défendent OOP ne font rien de sérieux. Ils ne font que des petites choses. Cependant, leur croyance dans la POO est inébranlable. D'autres qui fabriquent des mécanismes beaucoup plus sérieux sont beaucoup moins susceptibles de crier à la grandeur de la POO. Certains s'expriment même par des critiques (il y en a eu quelques unes).

Votre argument doit donc être étayé par la pratique, et pas seulement par la théorie. Je peux, par exemple, discuter des avantages de la POO dans le développement d'interfaces graphiques avec Anatoly, car nous pouvons comparer les solutions et leurs nuances dans la pratique. Mais, avec vous, je ne peux pas déployer mon argumentation car vous ne la comprendrez pas. Vous le ferez, mais vous ne le comprendrez pas (sans vouloir vous offenser). Anatoly, au contraire, peut très bien le comprendre. La différence d'expérience en matière de création de mécanismes mondiaux est la principale raison du malentendu.

SZY. En tant que praticien, je vous dirai ceci : l 'approche doit être telle qu'elle maximise le potentiel des cerveaux d'un programmeur particulier. J'ai trouvé une telle approche pour moi-même.

Les fantasmes sur OOP deviennent de plus en plus fous...

Le sérieux d'un travail est déterminé par le résultat, et non par le nombre d'années passées.

 
Реter Konow:

Hélas, ce ne sont pas des bêtises.

Le dessin sur toile ne nécessite pas de classe enveloppante. Une liste de fonctions est suffisante. Vous n'avez pas besoin de droits d'accès aux méthodes pour dessiner. Et tu le sais. Mais vous niez ce fait. Vous niez l'évidence.

Oh ! Oui. Pour manger une banane, vous devez éplucher la peau. Mais si une vache a des cornes, alors tout le monde avec des cornes est une vache.

 
Реter Konow:

Eh bien, il n'y a pas beaucoup de gens comme ça par ici. Je suis probablement l'un d'entre eux. Bien que, ce n'est pas pour vous apprendre. Juste pour entendre une réponse sensée. Pourquoi, lorsque vous dessinez, vous référez aux fonctions de la classe par des objets, si vous n'utilisez qu'UNE seule classe ?

Comme les fonctions de dessin sur le canevas ne font référence qu'au dessin sur le canevas et rien d'autre, il n'y a pas de raison de les garder dans un bac séparé, c'est pourquoi elles sont rassemblées dans une seule classe. Mais vous ne le comprendriez pas de toute façon.

 
Реter Konow:

Nikolaï, construisez-vous l'HIERARCHIE ou créez-vous des mécanismes de dessin ?

Si vous construisez une HIERARCHIE (sans vous soucier du dessin), alors il est clair que vous avez besoin de la POO partout.

Si vous créez un mécanisme de dessin qui fonctionne sur la base d'UNE classe, alors vous n'avez pas besoin de la classe elle-même.


Classe, - du mot Classification. La classification est une division par attributs. La classe est un dérivé de la classification. S'il y a une seule classe, alors il n'y a pas de classification.

Donc la classe, dans ce cas, est une connerie abstraite. Ça n'a pas de sens.

Qu'est-ce que la hiérarchie a à voir avec ça ? La POO fait un usage intensif de l'héritage... ...et encore une autre bande de fantaisie rampante...

 

...et la cerise sur le gâteau :

La cerise sur le gâteau

 
 


J'ai eu un projet similaire avec un autre logiciel assez coûteux, et j'ai également mis en œuvre l'idée en utilisant des solutions de contournement (afin de ne pas acheter de modules supplémentaires).

J'ai eu un projet similaire sur un autre logiciel spécial assez coûteux, j'ai également mis en œuvre l'idée par des solutions de contournement (afin de ne pas acheter de modules supplémentaires), cela a fonctionné, mais avec certains clients, on s'est retrouvé dans une impasse et on a perdu du temps...

Mais c'était un domaine complètement différent, il était facile de trouver des clients.

Raison: