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
Tags: design pattern, encapsulation, principe POO
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.
Commentaires
1. Le mardi 22 août 2006 à 21:39, par Christophe Moustier
2. Le samedi 26 août 2006 à 23:30, par Emmanuel Deloget
3. Le mardi 29 août 2006 à 23:48, par Christophe Moustier
4. Le mercredi 30 août 2006 à 14:22, par Emmanuel Deloget
5. Le dimanche 10 septembre 2006 à 22:24, par Victor Nicollet
6. Le lundi 11 septembre 2006 à 12:32, par Emmanuel Deloget
:: Fil rss des commentaires de ce billet ::
Ajouter un commentaire