La technologie objet via un langage, n'est qu'un principe qui permet de representer des entités en leur donnant des propriétées des méthodes, etc....
Lorque que tu programme, l'objet te permet d'encapsuler, protéger, sécuriser des données, facilité la maintenance du programme, permettre la réutilisation du code, abstraire, etc j'en passe....
Une fois que t'as programmé ton truc en objet, tu le passe au compilo/interpréteur et au final c'est un executable composé d'instructions de base qui est parcouru par le pointeur d'instruction de ton processeur.....
si tu le fais avec un langage non objet, au final t'auras aussi un executable qui est "lu" par ton proc et qui execute chaque instruction de base........
Donc tout ce que tu déclare comme objet ne l'est que du point de vue du programmeur et donc de dire qu'il doit y avoir une couche objet proche du noyau ne veut rien dire, si tu en veux programme là....
Tu feras pareil avec des API comme celle de QT, et tu pourras même manipuler des trucs bas niveau "à la façon objet".
Pour des utilisation en entreprise, ou multimédia, l'approche objet proche du centre, c'est à dire du noyau est indispensable. Dans une application de GED (j'en ai vu), l'approche objet sous windows permet de gérer toutte application gérant un format de fichier comme un objet.
Ceux que tu veux dire c'est que peut être, il faudrait une librairie multimédia objet : ptetre que SDL à des bindings C++, cherche par là....
L'API KDE est orienté objet, certes, mais les mécanismes objets sont uniquement présent à la surface et ne sont pas géré au coeur du système.
Le coeur du système, il ne sait traiter que des 0 et des 1, enfin bon ptetre que tu connais un langage équivalent en fonctionnalié/rapidité que l'assembleur qui est orienté objet...
[^] # Re: Un peu de tout :)
Posté par kolter (site web personnel, Mastodon) . En réponse au journal Un peu de tout :). Évalué à 3.
La technologie objet via un langage, n'est qu'un principe qui permet de representer des entités en leur donnant des propriétées des méthodes, etc....
Lorque que tu programme, l'objet te permet d'encapsuler, protéger, sécuriser des données, facilité la maintenance du programme, permettre la réutilisation du code, abstraire, etc j'en passe....
Une fois que t'as programmé ton truc en objet, tu le passe au compilo/interpréteur et au final c'est un executable composé d'instructions de base qui est parcouru par le pointeur d'instruction de ton processeur.....
si tu le fais avec un langage non objet, au final t'auras aussi un executable qui est "lu" par ton proc et qui execute chaque instruction de base........
Donc tout ce que tu déclare comme objet ne l'est que du point de vue du programmeur et donc de dire qu'il doit y avoir une couche objet proche du noyau ne veut rien dire, si tu en veux programme là....
[...]
MonObjet = word.openFile(NomFichier)
MaSousFenetreDansMonBrowserEnBasADroite = MonObjet.Show
[...]
Tu feras pareil avec des API comme celle de QT, et tu pourras même manipuler des trucs bas niveau "à la façon objet".
Pour des utilisation en entreprise, ou multimédia, l'approche objet proche du centre, c'est à dire du noyau est indispensable. Dans une application de GED (j'en ai vu), l'approche objet sous windows permet de gérer toutte application gérant un format de fichier comme un objet.
Ceux que tu veux dire c'est que peut être, il faudrait une librairie multimédia objet : ptetre que SDL à des bindings C++, cherche par là....
L'API KDE est orienté objet, certes, mais les mécanismes objets sont uniquement présent à la surface et ne sont pas géré au coeur du système.
Le coeur du système, il ne sait traiter que des 0 et des 1, enfin bon ptetre que tu connais un langage équivalent en fonctionnalié/rapidité que l'assembleur qui est orienté objet...
voilà voilà
M.