Architecture logicielle & Développement

Sur la programmation orientée objet | 1 vote(s)

Par Emmanuel Deloget, mardi 22 août 2006 à 09:32 :: Architecture Orientée Objet :: permalien #6

Mes lectures et mes interventions sur divers forums techniques (tel gamedev.net) m'ont appris que la notion de programmation orientée objet est floue dans l'esprit de beaucoup de programmeurs, y compris des programmeurs expérimentés. Tout au plus, ils imaginent que cela a trait aux classes et à l'héritage, certains y ajoutant le polymorphisme pour faire bonne figure.

Bien évidemment, cette vision extrêmement parcellaire de la programmation orientée objet est fausse. Tout d'abord, les classes, l'héritage et le polymorphisme sont des mécanismes de langage de programmation. Pour s'en convaincre, il suffit de vérifier deux choses : premièrement, je peux tout à fait écrire un programme orienté objet dans un langage n'ayant pas de structures équivalentes aux classes. C'est vrai en C (bien que dans ce cas, je vais probablement me servir de structures, qui présente une forte similarité avec une classe) mais c'est aussi vrai en LISP (dans ce cas, l'état de mon objet sera stocké dans une liste). Pour représenter un objet, la seule chose dont j'ai besoin est de pouvoir représenter son état. Or tous les langages propose au moins un moyen de regrouper plusieurs propriétés en un groupe cohérent : tableaux, listes, etc. Par conséquent, le fait de pouvoir créer une classe (au sens C++ du terme) n'est qu'une aide apportée au programmeur par le langage, et non pas quelque chose qui est intrinsèquement lié à la programmation orientée objet.

Ensuite, la notion d'héritage n'a de sens que si la notion de classe existe. Dans les langages ne supportant pas cette notion, on peut obtenir des résultats similaires en utilisant le mécanisme de composition des objets (qui est d'ailleurs souvent préférable, même dans les langages intégrant la notion d'héritage). De même, sans notion d'héritage, le polymorphisme d'héritage perd son sens. Il existe bien évidemment d'autres types de polymorphisme (polymorphisme ad hoc et polymorphisme paramétrique) mais il est trivial de constater que ces types de polymorphismes résultent de la construction du langage et ne sont pas des composantes intrinsèques de la programmation orientée objet.

Alors, qu'est ce qu'on appelle la programmation ou l'architecture orientée objet ? C'est le fait de découper un programme en objets qui interagissent les uns avec les autres et de prévoir ces interactions. Les objets ont un état et communiquent via des messages. Dans les langages orientés objets couramment utilisés, l'état est représenté par une liste de variables membres et les messages par des méthodes ou des fonctions membres mais il est tout a fait possible d'aller au delà de cette représentation - en LISP ou dans le langage RPN des calculateurs scientifiques HP série 48, l'état de l'objet sera stocké dans une liste et les messages seront représentés par d'autres listes décrivant des séries d'opérations. L'état de l'objet peut contenir la liste des messages qui lui sont associés, mais ce n'est pas une nécessité.

On voit que d'autres notions généralement associées à la programmation objet ne trouvent pas leur origine dans ce paradigme mais sont en fait des outils qui sont mis en oeuvre pour aider à la conception d'un programme en essayant de faire la meilleure utilisation possible de cette notion d'objet : les principes d'architecture objet, l'encapsulation - et par extension les notions sous-jacentes de contrôle d'accès - et autres patrons de conceptions n'ont qu'un lien tenu avec la définition de la programmation orientée objet - ils peuvent dépendre d'elle, mais l'inverse n'est pas vrai.

Trackbacks

Aucun trackback.

Les trackbacks pour ce billet sont fermés.

Commentaires

1. Le mardi 22 août 2006 à 21:39, par Christophe Moustier

Gravatar

En maîtrise, j'avais eu la définition d'un langage objet et ce langage devait posséder les propriétés suivantes :
- encapsulation,
- héritage,
- et polymorphisme.
La notion "d'orienté objet" et de permettre le développeur de faire "sans" ces paradigmes. Ainsi, le C++ est "orienté objet" contrairement à java, C# ou Eiffel où l'écriture de fonctions en dehors de toute classe est impossible.

2. Le samedi 26 août 2006 à 23:30, par Emmanuel Deloget

Gravatar

C'est une définition un peu étrange selon moi (mais étrangement, je ne suis pas connu pour la justesse de mon raisonnement en dehors d'un cercle restreint de personnes, principalement composé de moi-même d'ailleurs - et encore ne suis pas toujours d'accord avec ce que je dis).

Les propriétés d'héritage, encapsulation et polymorphisme ne sont, selon moi, que des aides offertes au programmeur afin de faciliter son travail. Ainsi, je ne vois pas en quoi supprimer l'héritage de la définition de C# ou Java diminue le coté 'objet' de ces langages.

Quand au langage "orienté objet", ils peuvent proposer ces fonctionalités (sans toutefois les implémenter complètement - c'est le cas du C++, qui n'implémente que partiellement la notion de polymorphisme). Ils peuvent donc aller au-delà de ces restrictions.

Pourrais-tu préciser davantage ta pensée STP, histoire que ça soit plus clair pour moi ? Danke :)

3. Le mardi 29 août 2006 à 23:48, par Christophe Moustier

Gravatar

>"supprimer l'héritage"
Qui a parlé de supprimer l'héritage ?!?
Java n'a que supprimé l'héritage multiple, pas l'héritage.

Ces aides dont tu parles sont des "grandes familles d'aides"...une sorte de "design pattern" fonctionnel si tu vois ce que je veux dire !

On constate que rester dans la combinatoire proposée par le langage objet laisse plus de portes ouvertes (cf ton article sur "open/close") qu'un mix de fonctions isolées et d'objets.

4. Le mercredi 30 août 2006 à 14:22, par Emmanuel Deloget

Gravatar

Je me suis mal fait comprendre :)

Ce que je voulais dire, c'est que si il me prend l'envie d'inventer un langage Java-- qui reprends exactement Java mais qui n'implémente pas l'héritage, la notion d'objet reste - et je peux en outre implémenter une notion proche de la notion d'héritage en utilisant la composition d'objets (bien sur, ce n'est pas aussi pratique, ni aussi simple).

Il est en outre évident que plus le langage offre de fonctionnalités, plus il est simple d'écrire un programme en utilisant ce langage (j'en veux pour preuve les difficultés supplémentaires qu'on peut éprouver a exprimer la solution a un problème en utilisant un langage purement procédural par rapport a celle qu'on rencontre lorsqu'on utilise un langage objet ou oriente objet).

Quand a l'article sur open/close, il faudra que je le rapatrie ici aussi :)

5. Le dimanche 10 septembre 2006 à 22:24, par Victor Nicollet

Gravatar

Ton observation initiale est très pertinente: l'idée d'orienté-objet est quelque chose de très flou, parce que le sujet est assez vaste pour y consacrer des livres entiers (des livres qui existent, d'ailleurs), que quelqu'un apprenant à utiliser le langage n'a pas besoin de lire pour écrire du code qui marche.

Le problème vient, en quelque sorte, de ce que les langages permettent la programmation orientée objet sans cependant contraindre les programmeurs à de bonnes pratiques. Bien sûr, l'éducation (écrite ou enseignée) n'est pas non plus innocente. Il faudrait insister plus sur le "code qui est flexible" que sur le "code qui marche": cette deuxième condition est déjà assurée par les compilateurs, c'est donc aux programmeurs de se dédier à la première.

Une lecture courte et gratuite que j'ai beaucoup appréciée est: _On Understanding Types, Data Abstraction and Polymorphism_, de Cardelli et Wegner. Cet article a l'avantage (à mon avis, c'est un avantage) de présenter ces concepts dans un cadre extérieur au langage de programmation de tous les jours. Les concepts sont donc purs, dans un langage très simple conçu dans le seul but d'expliquer à quoi ils servent, sans les alambications subtiles nécessaires dans un langage industriel.

6. Le lundi 11 septembre 2006 à 12:32, par Emmanuel Deloget

Gravatar

Merci Victor pour la réponse et l'article.

De plus en plus, les langages de programmation s'efforcent de mettre des contraintes sur le programmeur. Toutefois, ces contraines sont d'ordre syntaxiques et seules les bonnes pratiques affectées par la syntaxe peuvent être ainsi contrôlées. De fait, la responsabilité d'une architecture claire et flexible repose au final, il est vrai, sur les épaules du programmeur.

Je me demande si il est possible de concevoir un langage qui force le respect des principes de programmation orientée objet - ou au moins de certain d'entre eux.

Pour un lien sur l'article sus-mentionné:
citeseer.ist.psu.edu/card...
(Vous pouvez alors choisir de le télécharger dans différents formats).

:: Fil rss des commentaires de ce billet ::

Ajouter un commentaire

Si votre navigateur est compatible, vous pouvez vous aider de la barre d'outils placée au-dessus de la zone de saisie pour enrichir vos commentaires.