Discuter:Programmation orientée objet

Un article de Wikipédia, l'encyclopédie libre.

WikiProjet Informatique
 Programmation orientée objet fait partie du projet Informatique, qui a pour but d'enrichir le contenu de Wikipédia sur les sujets liés à l'informatique. Si vous voulez participer, vous pouvez modifier cet article ou visiter la page du projet où vous pourrez vous joindre au projet et consulter la liste des tâches et des objectifs. Le portail informatique pourrait aussi vous intéresser.
Bon début Cet article a été classé comme d'Avancement BD selon le Tableau d'évaluation du projet. (Voir les statistiques)
Élevée Cet article a été classé comme d'Importance élevée selon le Tableau d'évaluation du projet. (Contester?)

Remarque d'édition déplacée de la page article (HS et légèrement non-neutre) :

Cet article a été grandement remanié afin de donner un véritable aperçu de l'approche objet et non une appréciation uniquement dérivée de celle des langages à classes. Il est en effet malheureusement commun de trouver sur le web et dans les livres des définitions assez limitées de l'approche Objet avec un grand nombre d'idées préconçues dérivées directement de l'utilisation des langages à classes tels que C++ ou Java par exemple.

Désolé pour la notice CCM, apparemment, c'est moi qui me suis trompé. -- MM 9 jun 2003 ・16:10 (CEST)

Texte venant de programmation objet qui redirige ici maintenant :

La programmation Orientée Objet (POO) consiste à programmer des objets (modules) indépendants utilisables dans de nombreux programmes, par de nombreuses personnes (programmeurs), sans nécessairement en connaître les sources mais en utilisant les fonctionnalités. L'objet principal est une "classe". Elle est le coeur de langages orientés objets comme le Java ou le C#. Les programmeurs actuels utilisent de nombreuses classes déjà programmées (comme les MFC : Microsoft Foundation Class, ou les classes des librairies JAVA) afin d'accéder directement à des fonctionnalités évoluées (haut niveau).

UneClasse {

 prive:
   entier nombre;
 publique:
   entier valeur();
   entier incrementer();
   entier decrementer();

} Cet exemple de classe très simpliste permet à ses utilisateurs d'utiliser tout ce qui est publique (ici les méthodes valeur() (qui retourne l'entier nombre), incrementer() et decrementer() dont le sens est clair). Les "attributs" privés ne sont pas accessibles directement par l'utilisateur d'une classe.

Une fois la description des méthodes de la classe (code source) compilé en "module objet" ou ajouté à une librairie (.lib, .dll, ...) on peut utiliser cette classe depuis n'importe quel langage de programmation (qui supporte bien sûr les classes).

Sommaire

[modifier] Terminologie

Le problème posé par une description de l'approche objet est double :

  1. Il existe plus de mots différents que de choses à définir :o)
  2. Certains mots ne sont pas utilisés dans le même sens selon les sources

Sont ambigus par exemple, hors précision apportée par le contexte, le mot "objet", susceptible de deux sens différents et même opposés :

  • "Je vais prendre l'abscisse de l'objet z" ("objet" est utilisé ici avec le sens d'"instance")
  • "Je définis un objet que je nomme "nombre complexe"" ("objet" a ici au contraire le sens de "classe").

Les mots non susceptibles de polysémie (et de créer le trouble chez le lecteur novice) me semblent être :

Curieusement, il me semble que ces termes-là sont plutôt bien définissables ; ils appartiennent aux langages objets à classes. Ajouter également la notion de propriété ou fonction générique (sac de méthodes). Aurélien
Je pense aussi qu'il serait bon de définir ces termes. Harobed

Le mot "objet" est lui-même si protéiforme qu'il vaut sans doute mieux ne le conserver que de façon générique pour parler de l'ensemble comme de l' approche objet. Sinon, je crains que des faux problèmes crées par de seules questions de terminologie, sans aucune différence coincernant le fond, ne viennent perturber la cohérence de l'article. Qu'en pensez vous ? François-Dominique 5 sep 2004 à 09:22 (CEST)

Il y aurait aussi un lien à faire entre les Objets et les techniques de Représentation des Connaissances (RC) : réseaux sémantiques, logiques de description, graphes conceptuels, treillis de concepts, ontologies ... Un phd dans la salle ? Aurélien

[modifier] Proposition de révision

Je trouve le contenu de l'article assez intéressant. Par contre, je trouve aussi que l'article est mal construit. Voici les points qui me gênent:

  1. Le titre me paraît mal choisi. Je pense que Approche objet conviendrait mieux puisque l'article ne parle pas entièrement de programmation objet (note: je dis/écris programmation objet par habitude), mais aussi de conception de l'approche objet et de modélisation objet. Il me semble possible de faire de l'Objet sans avoir à programmer objet: par exemple, faire de la conception UML ce n'est pas programmer.
  2. La section Origine parle aussi des principes de l'approche objet (à ce propos, il y a une erreur dans cette section: il me semble que SmallTalk ne propose pas l'héritage multiple, tout au moins par défaut).
  3. Certaines parties me paraissent trop techniques (par exemple, la partie Typage et classification) et difficilement compréhensibles pour un novice.
  4. Des concepts importants me semblent oubliés, comme la communication par message par exemple.
ces deux derniers points devraient appartenir à un article "Langages à objets" Aurélien
Pour le typage et la classification: peut-être, pour la communication par message: pas d'accord. Par exemple, CORBA communique par message, mais il n'est pas question de langage. Dans ce cas, la communication par message semble mieux convenir au thème "Approche objet" qu'au thème "Langages objets". Kerflyn
Deux observations : tous les langages à objets n'acceptent pas la métaphore de l'envoi de message. Lorsque la sélection multiple est utilisée par exemple (CLOS) que signifie l'envoi de message ? Toute communication par message n'implique pas l'approche objet, il s'agit la plupart du temps de communication entre entités concurrentes et/ou distribuées. Aurélien
Je ne connais pas suffisamment CLOS. Par contre, il est toujours possible de dire que la plupart des systèmes basés sur l'approche objet utilisent la communication par message et qu'il y a quelques exceptions comme CLOS et Dylan. La métaphore de l'envoi de message se retrouve dans la plupart des documents expliquant l'approche objet, ainsi que dans mes cours (Alan Kay semble lui-même y faire allusion). C'est pour ça qu'elle me paraît importante. Kerflyn
J'ai une réserve profonde à l'encontre de l'envoi de message, même comme métaphore : l'envoi de message est une technique fondamentale pour la programmation de systèmes concurrents et/ou distribués. L'envoi de message dans ces cas sous-tend une communication asynchrone. Or dans tous les langages à objets considérés, il s'agit de communication synchrone. Si on conserve l'usage de cette métaphore, il faudra tout de même soulever le problème. Plutôt que parler métaphore, je préfère généralement expliquer qu'un appel de méthode (hors CLOS/Dylan) c'est la recherche (et l'invocation) dans l'espace de nom de la classe de l'objet receveur de la méthode la plus spécifique ... Enfin je reconnais que c'est dur d'aller contre trente ans de "métaphores" bien ancrées :) Aurélien

Je serais plutôt pour une refonte complète et un éclatement de l'artcle:

  • Je pense qu'un article sur l'approche objet allant à l'essentiel serait meilleur pour partager des connaissances. Des articles plus détaillés sur la programmation objet ou la conception objet pourrait être liés et consulté par le lecteur qui souhaite en savoir plus. Je pense même qu'une catégorie sur l'approche objet ne serait pas de trop. Il y aurait au moins les trois articles que je viens de citer, plus le Design Pattern, des articles sur des notions fondamentales en objet (communication par message, héritage, encapsulation, etc.), des éventuels articles sur les connecticiels/middleware objets (CORBA, Java RMI, COM/DCOM, Jonathan (Objectweb), etc.), sur la méta-programmation en objet (méta-classe, méta-objet, MOP, réflexion (Informatique), introspection, intercession, etc.), etc.
  • Bien séparer origine et principe. Dans la partie principe, il me semble important de nommer les principaux concepteur: Ole-Johan Dahl et Kristen Nygaard (Simula-I et Simula-67), Alan Kay (SmallTalk), tous détenteur d'un prix Turing.
  • D'autres points me paraissent importants: les problèmes liés à l'héritage multiple, les mixins (cf. Ruby), inconvénients de l'approche objet...
  • D'autres langages objets importants: Ruby, Objective-C, Ocaml, Oberon, Delphi.

- Kerflyn 20 avr 2005 à 09:55 (CEST)

Il faudrait au minimum deux articles pour commencer : langages à objet, objets et modélisation. A partir de là on peut subdiviser à nouveau. Aurélien
Je maintiens mon sentiment: il faudrait un article qui explique l'approche objet indépendamment de la technique employé pour l'implémenter (sous forme de langage, sous forme de middleware, sous forme SGBDOO, etc.). Kerflyn
Ce que tu veux c'est un article "théorie des langages à objet". Je suis pour, mais c'est un sacré gros travail et je ne suis moi-même que partiellement qualifié pour le faire. Il n'y a pas une théorie unique ou univoque sur les objets (contrairement à l'algèbre relationnelle par exemple). Aurélien
Non, il ne faut pas partir sur une théorie de l'approche objet. Je ne pense pas que ce soit le rôle de Wikipédia d'inventer quelque chose qui n'existe pas vraiment. Par contre, ce que nous pouvons faire, c'est présenter l'approche objet en générale, à la manière d'une introduction dans un cours, sans pour autant parler de programmation. Ainsi, le lecteur non-averti peut apprendre qu'il peut utiliser des objets sans le savoir et sans avoir à utiliser C++, Java ou CLOS. Les documents qui suivent peuvent nous y aider: [1], [2], ISO/IEC 10746-1:1998, page 11 (zip). Kerflyn
J'ajouterai le chapitre sur les objets de "Concepts, Techniques, and Models of Computer Programming" (Haridi & Van Roy) dans ta liste, alors ... Mais bon, tout reste à faire ... Aurélien

[modifier] PHP ?

pourquoi le PHP n'est pas considéré comme un langage objet pourtant php 5, gère relativement bien les classes...

PHP est une abomination, mais effectivement il est "orienté objet" depuis la v4. Mais ce n'est pas moi qui en parlerai ... :) Aurélien
"PHP est une abomination "[...] : Mouais... pas tout à fait d'accord. C'est un langage de script serveur, orienté objet, réflexif, souple et extrêmement concis. Comme avec tout les langages de la planète on peut faire de la purée avec, mais de mon point de vue, il est beaucoup plus abouti, depuis la version 5, que tu ne le laisses entendre! MyttO 30 jun 2005 à 12:19 (CEST)
Tu es responsable de tes opinions :) Mais ça serait cool, puisque tu as l'air de connaître, de faire un article détaillant les capacités objet de PHP 4,5. Je pense que l'article Common Lisp est un bon modèle de gros article sur un langage. Il ne faut pas se contenter de dire "le lang. FOO est orienté Objet et Tamère, et voici un exemple de trois lignes", il faut bien expliquer de quoi on parle. (Pour rester dans l'opinion, je crois que PHP arrive seulement à la hauteur de Python ou Ruby avec sa version 5 pour ce qui est des objets, et il y a toujours des choses horribles dans le langage). Aurélien
Tout doux! Je sais en quoi consiste un article de qualité. En l'occurrence, celui sur Common Lisp est effectivement bien structuré et rédigé. Pour ce qui est de PHP, je n'ai pas prévu un article pour le moment, j'avais juste envie de donner mon avis sur PHP qui attire souvent les foudres de certains intégristes, ce qui n'a pas l'air d'être ton cas, à cause de ses origines roturières. Je pense surtout qu'il faut commencer à se demander les raisons de son succès auprès d'un si grand nombre de professionnels. Mais loin de vouloir ouvrir un éternel débat sur les langages de orienté objet, je dirai que le véritable défit est de construire objet plus qu'utiliser tel ou tel langage. MyttO 30 jun 2005 à 22:28 (CEST)
Le Perl n'est pas dans la liste des langages Objet alors que son aspect Objet est plus poussé que celui de PHP.
Pourrait-on m'expliquer en quoi exactement le php est une "abomination" ? Je l'ai appris récemment et je le trouve formidable. Quels défauts exactement a-t-il en dehors de sa lenteur ? (à ce qu'on m'a dit). Concernent-ils uniquement la POO (que je n'utilise pas encore, et dont je peux me passer), où autre chose ?
Le PHP n'est pas une abomination dans sa totalité. C'est un très bon langage de script. Mais son approche objet est une abomination car elle n'est qu'un artefact pour le codeur. PHP n'exploite pas assez ses objets, surtout en comparaison avec les autres langages objet utilisables côté serveur (tous les langage dans le concept CGI, mais JSP ou ASP en particulier). En PHP les objets persistent difficilement en mémoire, ne sont pas exploitables entre les applications serveurs directement, obligé de les écrire sur le disque (BDD ou fichier plat). Quand des objets sont passés d'une page d'un client à l'autre via sa variable de session, les classes doivent être redéfinies dans le script suivant pour que PHP puisse utiliser ce qu'il a stocké dans la session. Ce qu'il manque au PHP c'est tout bonnement la part "serveur d'applications". En PHP, on ne fait pas une application qui tourne en permanance et répond aux requètes. Le PHP ne s'éxécute qu'en réponse à une requète. Si il n'y pas de visite sur le site, le site ne fait rien — à moins de coupler avec d'autres technologies, bien sûr, mais nous ne parlerions plus alors de PHP. Bref, de mon point de vue, l'objet en PHP ne sert qu'à écrire et factoriser son code différemment... Celà etait mon 1er appriori. J'ai ensuite découvert que l'en utilisant non plus PHP en CGI (Common Gateway Interface) en CLI (Command Line Interpretor), on pouvait "s'amuser" à faire communiquer les différents processus de la machine, crée des sockets qui écoutent directement le port 80 et l'HTTP pour faire un serveur PHP... — Il existe d'ailleur, et par ailleur, des bots pour IRC ou autre protocole de chat en PHP. Là, tout de suite, la communauté se restreint à quelques vénérables geeks. Une approche interressante qui, à mon avis, ne mérite d'être explorée que pour la curiosité. Cortex

Plus que de longs discours, voici un petit programme utilisant les fonctionnalités "objet" de PHP 5 :

class A {
        public $nom;
        private $pass;
        public function __construct($nom,$pass){
                $this->nom=$nom;
                $this->pass=$pass;
        }
        public function getPass(){
          echo $this->nom."  ".$this->pass."<br>\n";
        }
}

$X=new A("Jean","xxxx");
$X->getPass();

$X->__construct("Pierre","bidon");

$X->getPass();

Que les détracteurs et les partisans de PHP l'essaient... Chacun en ce qui le concerne se fera une opinion (ou la renforcera) !!!;o)

[modifier] Programmation objet et messages

Merci beaucoup Aurélien pour la référence à Haridi & Van Roy. Je n'ai pas trouvé leur livre, mais leurs sites web sont très fournis et très intéressants [3]. Par exemple, c'est la première que je vois des critiques sur l'héritage (j'ai en effet rencontrer plusieurs problèmes ayant pour origine l'héritage). Je comprend mieux pourquoi des langages comme C++ ou Java ne sont pas vraiment des langages objets, contrairement à Caml, Smalltalk et aussi Oz (il y a quelques années, j'avais participé à une réunion de chercheurs en technologies objets qui condamnaient Java; à l'époque, je ne comprenais pas leur point de vue).

Je me pose toujours des questions sur ce qui tu écris sur l'envoi de messages. Je ne pense pas que la communication par message implique forcément une communication asynchrone. Même si la communication facilite ou simplifie la communication asynchrone, elle peut convenir dans le cadre de la communication synchrone. Bon, je n'ai pas d'exemple précis... En ce qui concerne l'utilisation de la communication par message dans la programmation objet, il semble que cette "métaphore" soit utilisée par Haridi (ou Van Roy, ou les deux). Sinon, j'ai aussi trouvé ce lien vers un cours de Malenfant, qui se base sur la communication par message en programmation objet pour montrer, par exemple, comment il est possible d'obtenir des fonctions génériques sous CLOS (cas de réflexion comportemantale) [4].

--Kerflyn 30 jun 2005 à 22:43 (CEST)

--Nicolas BOITEUX 12 octobre à 16:31 (CEST)

L'ensemble des messages forme ce que l'on appelle l'interface de l'objet ; c'est seulement au travers de celui-ci que les objets interagissent entre eux. La réponse à la réception d'un message par un objet est appelée une méthode (méthode de mise en œuvre du message) ; elle décrit comment est réalisé le message.

Le résultat renvoyé par un objet à un message n'est pas une méthode. Une interface déclare des méthodes publiques/visibles. Il n'y a pas de lien direct entre la définition d'une interface et d'un message.

Un objet émet un message quand il fait appel à la méthode d'un autre objet, celle-ci peut être ou non déclaré explicitement dans une interface.


Le bouquin est même accessible (c'est un draft, mais il a l'air complet) ici : http://www.ulb.ac.be/di/rwuyts/INFO020_2003/vanRoyHaridi2003-book.pdf ... La je n'ai pas le temps, mais je reviendrai sur cette histoire d'envoi de message (synchrone/asychrone), parceque c'est un point difficile et souvent mal compris. Ca mérite même un article. Aurélien