Représentation d'un objet en programmation. - page 9
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
En quoi consistent les "annexes" ?
Dans les langages d'application.
Partie 2.
Dans la première partie, nous avons parlé des constituants de l'objet, mais dans cette partie nous allons examiner leurs relations entre eux. Les composants eux-mêmes seront conventionnellement appelés"Proto-blocs", parce qu'ils ne sont pas des objets à part entière, mais représentent certaines entités "de construction" qui font partie de tous les objets et systèmes. Permettez-moi de vous rappeler leur liste initiale :
En plus du "corps" paramétrique de Form, State, Event et Process, nous ajouterons une fonction handler (appelons-la simplement "handler") dont la tâche est de "transférer" les valeurs de son proto-bloc vers l'ensemble paramétrique de l'objet. Par exemple : une étiquette possède 5 paramètres dans une fonction de construction et cet ensemble constitue son "corps" paramétrique. Supposons que nous ayons inventé un nouvel état et que nous l'ayons écrit sous la forme de différentes valeurs des paramètres initiaux. Au moment où nous devons déplacer l'étiquette vers un nouvel état, nous devons appeler une fonction qui les transfère de la structure paramétrique de l'état au "corps" paramétrique de l'étiquette. En termes simples, ce gestionnaire initialise les paramètres Object avec les valeurs de son proto-bloc. Pour Process et Form, un principe similaire fonctionne avec le transfert de la valeur vers le corps de l'objet, mais la mise en œuvre est différente. Mais pour traiterun événement , nous n'avons pas besoin de transférer les valeurs - nous devons les vérifier, donc une déclaration de condition fera office de gestionnaire.
Il y a beaucoup de manipulateurs dans mon concept et ils méritent une classification séparée, mais cela compliquerait trop la présentation et je vais donc les aborder superficiellement, en les divisant grossièrement en plusieurs groupes :
Cette liste n'est en aucun cas exhaustive et les noms des manipulateurs sont arbitraires, mais la répartition de leur spécialisation, en général, ressemble à ceci.
L'ajout suivant au concept, après les fonctions de gestionnaire, serait les"modules". Il est logique de supposer que les proto-blocs créés doivent être stockés et organisés quelque part, et il est également facile de deviner qu'il serait optimal de séparer le stockage des proto-blocs de différents types pour éviter toute confusion et permettre aux manipulateurs de "naviguer" facilement dans le contenu croissant de l'objet. Nous créons donc des "stockages" ou, ce qui est encore plus beau, des"modules" de proto-blocs. Pour les États, les processus, les événements et les formes de l'objet seront créés leurs propres modules dans lesquels les proto-blocs seront :
Le quatrième point - qui consiste à "relier" des proto-blocs de différents types - repose précisément sur leur "inclusion structurelle" les uns dans les autres, dont j'ai parlé dans la première partie - Le processus inclut les États,... L'événement comprend l'État,... Un procédé comprend des événements,... Un État peut inclure un formulaire, et ainsi de suite... Par exemple, si nous construisons un modèle d'événement dans un module distinct, sa hiérarchie de conditions contiendra des événements stockés dans le module "Event", et ces événements contiendront à leur tour des états stockés dans le module States. De cette manière, nous créons non seulement un moyen efficace de stocker et d'utiliser les proto-blocs, mais nous mettons également en œuvre leur "inclusivité structurelle" en les reliant simplement les uns aux autres par des liens entre les modules. En modifiant les liens de façon arbitraire ou réfléchie, nous pouvons créer de nouveaux proto-blocs à partir de ceux qui existent déjà, ainsi que modifier le modèle d'événement ou de logique dans le "comportement" de l'objet. En modifiant les relations au niveau du modèle logique (qui sera à son tour stocké dans son module), on peut changer complètement le programme, et ce faisant, on ne doit rien réécrire dans le code. C'est là que je vois les avantages de la séparation modulaire des proto-blocs.
C'est tout pour le moment. Ensuite, je passerai aux modèles d'événements et aux modèles logiques et j'examinerai comment ils sont construits.
Posez des questions si quelque chose n'est pas clair ou intéressant.
A quoi sert le concept ?
Ce concept est une tentative de passer au niveau suivant de la programmation, qui, à mon avis, consistera à "construire" (plutôt qu'à écrire) des systèmes fonctionnels par l'ordinateur lui-même, plutôt que par des humains. Le logiciel sera capable de créer des programmes.
Il existe désormais un réseau neuronal formé sur le code githab, mais ce n'est pas du tout ce que je veux dire.
Ce concept est une tentative de passer au niveau suivant de la programmation, qui, à mon avis, consistera à "construire" (plutôt qu'à écrire) des systèmes fonctionnels par l'ordinateur lui-même, plutôt que par des humains. Le logiciel sera capable de créer des programmes.
Il existe désormais un réseau neuronal formé sur le code githab, mais ce n'est pas du tout ce que je veux dire.
Bonjour Peter.
Outre la POO, il y a la DDD(conception pilotée par le domaine)
Juste pour vous tenir informé.
Bonjour Peter.
En plus de la POO, il existe la DDD(conception pilotée par le domaine)
Pour votre information.
Tu confonds le chaud et le doux.
Tu confonds le chaud et le doux.
Où est le signal, mon frère ?
Où est le signal, mon frère ?