Quelles sont les fonctionnalités requises pour l'orientation des objets?

Je me demande simplement quelles sont exactement les fonctionnalités qu'un langage ou une bibliothèque doivent fournir pour être défini comme «orienté objet». L'orientation objet est-elle quelque chose qui peut, plus ou moins, être réalisé dans n'importe quel langage de programmation à usage général avec des fonctionnalités décentes? Ou est-ce quelque chose qui ne peut être réalisé que dans des langages qui annoncent spécifiquement qu'ils prennent en charge la programmation orientée objet?

Par exemple, regardez le code C suivant:

SDL_Surface* screen = SDL_SetVideoMode( 640, 480, 16, SDL_HWSURFACE);
SDL_FreeSurface( screen );

ou le code discuté ici .

Maintenant, le code ci-dessus n'utilise pas l'héritage, le polymorphisme d'exécution (?), Les fonctions virtuelles, etc. Mais il me semble à peu près OOP.

L'orientation objet est-elle simplement en train d'écrire du code qui est basé sur des structures de données créables et destructibles telles que des objets, des classes, des structures, etc., qui ne nécessitent aucun modèle ou fonctionnalités spéciales fournies par le langage de programmation ou une bibliothèque ?

Selon Alan Kay, qui a inventé le terme "orienté objet",

Pour moi, la POO signifie uniquement la messagerie, la conservation et la protection locales et la dissimulation du processus étatique, et la liaison tardive extrême de toutes choses. Cela peut être fait dans Smalltalk et dans LISP. Il existe peut-être d'autres systèmes dans lesquels cela est possible, mais je ne les connais pas.

La messagerie (telle qu'implémentée dans Smalltalk) est un concept comparable au polymorphisme, mais plutôt plus puissant (au moins que le type de polymorphisme pris en charge par C ++ ou Java). Cela peut être fait dans toutes les langues, mais est plutôt douloureux s'il n'est pas pris en charge directement par la langue. Fondamentalement, cela signifie que les objets peuvent s'envoyer des messages contenant n'importe quoi, amd peut réagir comme ils le souhaitent aux messages qu'ils reçoivent. Pour prendre pleinement en charge la messagerie, il doit exister un moyen pour les objets de réagir de manière flexible aux messages sans les énumérer dans le code source (c'est essentiellement ce que font les définitions de méthode / fonction).

la rétention et la protection locales et la dissimulation du processus d'état - l'encapsulation AKA - peuvent être effectuées par convention dans toutes les langues, mais cela triche quelque peu. La rétention locale au niveau de la langue semble en fait être la seule fonctionnalité que toutes les langues qui prétendent être OO (et beaucoup d'autres) ne partagent pas - il existe généralement un moyen de créer des types de données composés avec plusieurs instances. La protection et la dissimulation, en revanche, ne se font souvent que par convention.

liaison tardive de toutes choses - une échelle mobile sur laquelle C est vraiment loin de la vision de Kay (tout comme C ++, tandis que Java est beaucoup plus proche). Peut être truqué (voir COM), mais ce sera pénible à utiliser.

Notez que Kay ne mentionne pas l' héritage . Dans le même e-mail qu'il a écrit

Je n'aimais pas la façon dont Simula I ou Simula 67 faisait l'héritage (même si je pensais que Nygaard et Dahl n'étaient que de formidables penseurs et concepteurs). J'ai donc décidé de laisser l'héritage en tant que fonctionnalité intégrée jusqu'à ce que je le comprenne mieux

La programmation orientée objet ne concerne pas les fonctionnalités de syntaxe, c'est une philosophie de codage et de conception. À sa base se trouve le concept d'un objet , qui est une construction qui regroupe l'état avec des routines pour agir sur lui (ou, selon votre point de vue, les réponses aux messages). L'autre aspect important de la POO est l' encapsulation : envelopper les détails d'implémentation dans des structures opaques et les connecter via des interfaces bien définies. Presque tout le reste de la théorie de la POO remonte à ces deux principes fondamentaux.

Ainsi, tout langage qui peut en quelque sorte modéliser des objets (entités qui contiennent à la fois des données et du code) et l'encapsulation peut être utilisé pour faire de la POO. Par exemple, en C, vous pouvez utiliser des pointeurs de fonction pour stocker des fonctions dans des structures, et vous pouvez utiliser le système de fichiers en-tête / source pour réaliser l'encapsulation. Ce n'est pas pratique, mais c'est suffisant pour faire de la POO. Vous pouvez probablement même plier quelque chose comme Haskell ou ML pour faire de la POO, et je ne serais pas surpris si quelqu'un pouvait trouver une façon de faire la POO en assemblage.

En pratique, cependant, un langage peut être appelé «orienté objet» s'il fournit un ensemble complet de fonctionnalités de syntaxe pour une programmation orientée objet explicite. Typiquement, cela signifie qu'un tel langage devrait avoir: * une notion d'objet * une notion d'appel de méthode ou de passage de message * une manière confortable et simple de contrôler l'accès aux membres de l'objet * une manière confortable et simple de définir les interfaces

Par conséquent, j'appellerais un morceau de code orienté objet s'il adhère aux principes de la POO et utilise la syntaxe de POO disponible.

BTW., Votre exemple de code probablement fait polymorphisme l' utilisation et les fonctions virtuelles, bien que la syntaxe C ne rend pas évidente. Je ne suis pas un expert en SDL, mais je m'attendrais à ce SDL_surfacequ'il soit en mesure de représenter différents types de surfaces, chacune avec son propre ensemble spécifique d'implémentations - le fait de coller quelque chose sur une image bitmap de mémoire et de bliter sur une surface d'écran nécessite des différences radicalement différentes mais l'interface (les fonctions qui prennent un SDL_surface*comme argument) reste la même. Tout comme cela, il implémente également l'encapsulation: vous ne pouvez pas accéder directement à la représentation sous-jacente d'une surface, vous devez passer par des fonctions qui savent comment gérer un SDL_surface, car c'est tout ce que vous avez. C'est un bel exemple de la façon dont vous feriez la POO en C.

Ma compréhension de l'OO est que l'OO est une façon de penser et une implémentation qui est basée sur l'idée qu'une tâche de calcul peut être réalisée par un travailleur (objet) ou par la collaboration de travailleurs individuels (objets) via un message passant entre ces travailleurs ( objets) au moment de l'exécution. Ce comportement au moment de l'exécution nécessite des constructions statiques et dynamiques solides pour l'activer.

La syntaxe spécifique pour implémenter OO n'est pas la clé qui détermine si une langue est un OO ou non. Par exemple, Smalltalk et C # ont des syntaxes différentes mais les deux sont des langages OO (à des degrés divers). La clé est de savoir si le langage donné préserve la philosophie (ci-dessus) et fournit les moyens d'implantation requis.

Quand j'étais étudiant, on m'a enseigné que la programmation orientée objet repose sur trois piliers:

• encapsulation ,
• polymorphisme , et
• héritage .

Un langage devra prendre en charge ces fonctionnalités pour être considéré comme un langage orienté objet.

Notez que cela décrit un ensemble de fonctionnalités plutôt qu'une syntaxe . Par conséquent, si vous devez écrire

type obj; // or type obj = new type;
obj.func(arg);

ou

type* ptr = create_type();
func(ptr, arg); 

n'a pas d'importance.

Vous pouvez donc bien programmer selon le paradigme orienté objet en C. Mais le langage n'offre aucun support pour cela, ce qui en fait un exercice assez pénible. C'est pourquoi C n'est pas considéré comme un langage orienté objet.

Vous pouvez faire OO dans n'importe quelle langue convenable à usage général.

Il est plus facile de le faire dans un langage "OO", car vous avez des constructions idiomatiques disponibles et vous n'avez pas à recourir à quelque chose comme OO en C - ce qui est possible, mais horrible.

Que les constructions OO soient fournies par le langage lui-même, par sa bibliothèque standard ou par une autre bibliothèque, peu importe, car certaines langues (par exemple Scala) permettent aux bibliothèques d'ajouter des constructions de langage de sorte que du point de vue du programmeur, il est presque impossible pour distinguer quels éléments sont fournis par le langage principal et lesquels par une bibliothèque.

Si vous regardez la gamme de langages qui ont été largement acceptés comme OO et ceux qui ne l'ont pas, le test semble être le support du polymorphisme d'inclusion (alias polymorphisme de sous-type, mais le polymorphisme d'inclusion est le terme utilisé par Cardelli dans le papier qui m'a présenté, et je pense que beaucoup d'autres, à une classification des types de polymorphisme). IE la possibilité pour certaines variables d'avoir des valeurs de types différents et la possibilité pour certains appels de se répartir sur différentes routines en fonction du type d'une ou plusieurs valeurs. Tout le reste était présent dans des langues non acceptées comme OO ou manquait dans des langues bien acceptées comme OO.

Les deux autres principales caractéristiques associées aux langues OO ont été fournies par des langues non OO:

• L'encapsulation est assez bien fournie par Ada83;
• L'héritage est fourni par Oberon (Oberon est intéressant, Wirth voulait fournir un langage OO avec le moins de cru possible, mais a dû revoir sa conception pour en obtenir un - Oberon-2 est OO).

L'orientation de l'objet est définie comme

• Polymorphisme
• Héritage
• Encapsulation

consultez également les entrées wikipedia. ce sont les fonctionnalités qu'un langage doit fournir pour qu'il soit défini comme orienté objet.

considérez votre code orienté objet s'il se trouve dans un langage de programmation orienté objet. même si vous écrivez quelque chose qui semble être procédural, il agira sur les méthodes des objets des classes utilisant le polymorphisme via l'encapsulation [peut-être] :)

en ce qui concerne votre dernière question, la réponse est probablement. Oui. orienté objet agit simplement sur les méthodes des objets et passe ces objets en tant que paramètres.