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

 
De quoi s'agit-il ? Pourquoi le noyau ne peut-il pas contenir un tableau de structures/classes (fenêtre, bouton, etc.) ? (rhétorique).
Achèteriez-vous un seau de composants radio au lieu d'une télévision ? De la même manière, un noyau n'a pas besoin de s'embarrasser de détails. Mais c'est vous qui décidez, tant que c'est pratique - bien.
 

Le moteur travaille avec le noyau en utilisant une technique que j'appelle"Focus Elements" (peut-être pas un bon nom).

L'idée est la suivante :

En déplaçant le curseur dans le graphique, l'utilisateur franchit les limites des objets. Chaque élément a son propre territoire dans l'espace graphique. Une fonction spéciale surveille les coordonnées du curseur et indique sur quelle fenêtre et quel élément se trouve le curseur.

Le numéro de la fenêtre et de l'élément dans le noyau, sont écrits dans les variables globales. Le moteur les utilise ensuite pour accéder au noyau et récupérer toutes les valeurs actuelles des propriétés de la fenêtre, de l'élément et de l'objet où se trouve le curseur.

Lorsqu'un événement se produit (clic, appui, double-clic, etc...), le bloc, qui traite cet événement, SAIT immédiatement dans quelle fenêtre et avec quel élément cet événement s'est produit.

Les principales propriétés de la fenêtre, de l'élément et de l'objet, sont déjà en focus (c'est-à-dire déjà stockées dans des variables globales), et utilisées dans le code immédiatement.

C'est très efficace.

C'est pourquoi le noyau devrait être un simple tableau global.
 
Реter Konow:

...

C'est pourquoi le noyau devrait être un simple tableau global.

Les tableaux de pointeurs sont connus depuis longtemps dans la nature.

Tant d'efforts pour réinventer la roue... Tout est là et sous une bien meilleure forme.

C'est une chose amusante à propos de la POO - elle provoque beaucoup de résistance psychologique chez les gens. Même lorsque vous ne devez pas écrire de classes, mais seulement les utiliser.

Pourquoi se limiter à un seul noyau. Dans le cadre de cette approche du noyau, la POO n'est qu'un générateur de noyau enragé.

 
Dmitry Fedoseev:

Les tableaux de pointeurs sont connus depuis longtemps dans la nature.

Tant d'efforts à dépenser pour réinventer la roue...

Vous voyez, tout cela implique l'utilisation d'une syntaxe supplémentaire, qui n'est pas nécessaire en pratique. La solution ne nécessite pas cette syntaxe et des outils supplémentaires.

La solution est peut-être primitivement simple, mais elle est TRÈS efficace. C'est exactement ce que je m'efforce de faire.

 
Dmitry Fedoseev:

Pourquoi se limiter à un seul noyau. Dans le cadre de cette approche du noyau, la POO n'est qu'un générateur de noyau enragé.

Pourquoi la POO est-elle présente si la solution ne l'exige pas ?

Les fenêtres, les éléments, les objets sont représentés et ordonnés dans le noyau. On y accède par un index de tableau ou par le focus des éléments.

Pourquoi des pointeurs, des références, des classes, des constructeurs, des destructeurs, et un million d'autres choses quand la solution existe déjà ?

Il est simple et autosuffisant.


Nous avons besoin de la POO dans un but tout à fait différent. J'aurais besoin de la POO si je créais cette technologie avec une équipe d'autres développeurs et que chacun d'entre nous ne faisait qu'une partie du travail.

 
Реter Konow:

La POO a un but complètement différent. J'aurais besoin de la POO si je créais cette technologie avec une équipe d'autres développeurs, et que chacun d'entre nous ne faisait qu'une partie du travail.

Monsieur. Eh bien TC, donnons des exemples de tes idées en code, discutons du fait que la POO est "mauvaise" plus tard ... comme on dit : Codes sur la table ! )))

 
  1. La POO est nécessaire pour garantir qu'une équipe de développeurs travaillant sur un même programme travaille ensemble de manière harmonieuse.
  2. La POO est nécessaire pour comprendre et modifier le code écrit par l'équipe de développement.

MAIS, la POO n'est pas nécessaire lorsqu'il n'y a qu'un seul programmeur et que ses tâches ne nécessitent pas la POO.

 
Vous vous noierez dans votre technologie après une pause de deux mois en essayant de terminer quelque chose. Et votre constructeur n'est probablement pas assez sophistiqué puisque la complexité de la mise à l'échelle n'est pas devenue claire.
 
Igor Makanu:

Monsieur. Eh bien, donnons des exemples de vos pensées en code, nous discuterons plus tard du fait que la POO est "mauvaise"... comme on dit : Codes sur la table ! )))

Oui, je vais préparer des exemples simples.

 
Реter Konow:
  1. La POO est nécessaire pour garantir qu'une équipe de développeurs travaillant sur un même programme travaille ensemble de manière harmonieuse.
  2. La POO est nécessaire pour comprendre et modifier le code écrit par l'équipe de développement.

MAIS, la POO n'est pas nécessaire lorsqu'un seul programmeur travaille et que ses tâches ne nécessitent pas l'utilisation de la POO.

Les deux thèses sont fausses.