Non, c'est une erreur. C'est un peu comme dire que la poésie ne peut s'exprimer qu'avec des vers, et réciproquement.
class Toto
{
public:
int x;
private:
int y;
}
int main (void)
{
Toto t;
int x;
for (x=0;x<sizeof(t);++x) *(((char *)&t)+x)=0; // Ecrase tout.
return 0;
}
Et voila, j'accède aux membres privés de l'objet "t".
La seule chose qui puisse m'empêcher de faire cela est un typage fort. Cela n'a rien à voir avec l'orienté objet. La POO est une vue d'esprit. Il ne faut jamais oublier que les différents appels aux méthodes d'un objet en particulier seront résolus en sauts vers des fonctions, évidement en exemplaire unique en mémoire, et qui recevront implicitement un pointeur ou une référence sur les données de l'objet qui se résume à une simple structure de données. D'ailleurs il me semble même qu'en Python, l'équivalent de "this" est passé explicitement (je ne fais pas de python).
En ce sens, GTK+ et même la X-lib ont une approche orientée objet de la chose. Il peut exister plusieurs entités appartenant à une même catégorie, et sur lesquels peuvent par conséquent s'appliquer toute une batterie de fonctions destinées à la gestion des objets de cette catégorie. Exemple: les Drawables. Le fait que l'on invoque ces facilités à l'aide d'une méthode d'un symbole donné, ou que l'on se réfère à cette entité un utilisant un handler sous la forme d'un entier transmis à l'appel de la fonction revient au même.
D'autre part, il faut également toujours garder à l'esprit que tout le code écrit sera au final traduit en langage machine. La programmation ne s'aborde pas comme un problème mathématique dans lequel la finalité ne consiste qu'à résoudre une équation. Chaque action consomme des ressources en temps système et en mémoire, et il appartient au programmeur de connaître ses spécificités, et éventuellement d'utiliser des raccourcis si cela est profitable à l'utilisateur final. D'une manière générale, l'optimisation d'un programme devrait à mon goût occuper autant de temps que la rédaction et le débuggage de ce programme. C'est spécialement vrai lorsque l'on utilise un langage interprété ou un système de byte-code.
Tout cela pour dire que l'approche objet est un framework comme un autre. L'utilisation d'un langage orientée objet est une chose naturelle lorsque tout un projet est axé autour de ce concept, mais c'est loin d'être une nécessité.
[^] # Re: Le langage du futur ?
Posté par Obsidian . En réponse au journal Le langage du futur ?. Évalué à 1.
Non, c'est une erreur. C'est un peu comme dire que la poésie ne peut s'exprimer qu'avec des vers, et réciproquement.
class Toto
{
public:
int x;
private:
int y;
}
int main (void)
{
Toto t;
int x;
for (x=0;x<sizeof(t);++x) *(((char *)&t)+x)=0; // Ecrase tout.
return 0;
}
Et voila, j'accède aux membres privés de l'objet "t".
La seule chose qui puisse m'empêcher de faire cela est un typage fort. Cela n'a rien à voir avec l'orienté objet. La POO est une vue d'esprit. Il ne faut jamais oublier que les différents appels aux méthodes d'un objet en particulier seront résolus en sauts vers des fonctions, évidement en exemplaire unique en mémoire, et qui recevront implicitement un pointeur ou une référence sur les données de l'objet qui se résume à une simple structure de données. D'ailleurs il me semble même qu'en Python, l'équivalent de "this" est passé explicitement (je ne fais pas de python).
En ce sens, GTK+ et même la X-lib ont une approche orientée objet de la chose. Il peut exister plusieurs entités appartenant à une même catégorie, et sur lesquels peuvent par conséquent s'appliquer toute une batterie de fonctions destinées à la gestion des objets de cette catégorie. Exemple: les Drawables. Le fait que l'on invoque ces facilités à l'aide d'une méthode d'un symbole donné, ou que l'on se réfère à cette entité un utilisant un handler sous la forme d'un entier transmis à l'appel de la fonction revient au même.
D'autre part, il faut également toujours garder à l'esprit que tout le code écrit sera au final traduit en langage machine. La programmation ne s'aborde pas comme un problème mathématique dans lequel la finalité ne consiste qu'à résoudre une équation. Chaque action consomme des ressources en temps système et en mémoire, et il appartient au programmeur de connaître ses spécificités, et éventuellement d'utiliser des raccourcis si cela est profitable à l'utilisateur final. D'une manière générale, l'optimisation d'un programme devrait à mon goût occuper autant de temps que la rédaction et le débuggage de ce programme. C'est spécialement vrai lorsque l'on utilise un langage interprété ou un système de byte-code.
Tout cela pour dire que l'approche objet est un framework comme un autre. L'utilisation d'un langage orientée objet est une chose naturelle lorsque tout un projet est axé autour de ce concept, mais c'est loin d'être une nécessité.