Les langages de programmation – Partie 2 : Le modèle objet

Après vous avoir parlé des langages que je connais (petit moment narcissique inutile), je vais maintenant partager quelques réflexions concernant le modèle objet, et comment il est implémenté dans les langages de programmation.

Les objets, l’héritage et le polymorphisme

La notion la plus importante de la programmation orientée objet, c’est… l’objet (tadaa !), une structure qui encapsule en même temps des données et les traitements qui y sont associés. Très vite, on trouve derrière l’héritage et le polymorphisme.

L’héritage : Un objet peut dériver d’un autre. Il en reprend toutes les caractéristiques, en y ajoutant des attributs (données) et/ou des méthodes (traitements) supplémentaires. La plupart du temps, il est même possible de suppléer une méthode de l’objet parent, en redéfinissant une méthode du même nom.

Prenons un exemple. L’objet Véhicule possède les attributs poids et vitesse, et la méthode avance. Les objets Voiture et Camion héritent de Véhicule, en ajoutant des attributs supplémentaires. Voici un petit diagramme UML :

Si on crée une instance de l’objet Voiture, on aura accès aux attributs poids, vitesse et nombre_passager, et aux méthodes avance et allume_autoradio.

Le polymorphisme : Tous les objets qui dérivent d’un même objet (avec différent sous-types) peuvent être manipulés comme s’ils étaient du type de l’objet parent − tant qu’on n’utilise que leur partie commune.

Si on reprend l’exemple précédent, toutes les instances des objets Voiture et Camion peuvent être manipulées comme si elles étaient du type Véhicule. Si on veut calculer leur poids total, il suffit d’additionner la somme des poids de tous les véhicules, sans avoir besoin de savoir s’il s’agit de voitures ou de camion.

Par contre, seuls les camions peuvent charger une cargaison.

Après l’héritage et le polymorphisme, on peut ajouter l’encapsulation et la notion de visibilité, qui permettent de déterminer les règles d’accès aux attributs et aux méthodes dans les objets et depuis l’extérieur des objets. Bien que ces notions soient très répandues, il existe des langages orientés objet qui ne les supportent pas (Javascript, Python).

Implémentation des types d’héritages

Il existe deux types d’héritage : l’héritage simple et l’héritage multiple.

L’avantage de l’héritage multiple, c’est qu’il permet − comme son nom l’indique − à un objet d’hériter de plusieurs objets à la fois. Parmi les langages qui le supportent, je ne connais vraiment que le C++ et le Perl,  sans oublier le Python (que je connais mal) ; il en existe d’autres, qui sont plutôt exotiques (Eiffel, OCaml, …).

La plupart des langages ne supportent que l’héritage simple. Enfin, c’est l’impression que j’ai, je ne peux pas vraiment l’étayer de manière formelle. Mais si on prend l’exemple du Java, du PHP, du Ruby… ça semble être la mode.

Toujours sans la moindre preuve, j’ai tendance à penser que l’héritage multiple est mis de côté pour simplifier le développement des langages. Je m’explique. Dans les années 80, il n’existait pas de compilateur C++. Bjarne Soustrup, son créateur, avait mis à disposition un programme qui traduisait du code C++ en code C, qui pouvait alors être compilé. J’ai été amené, durant mes études, à m’intéresser à ce type de translateur, et c’est très intéressant.

Ce qu’il faut comprendre, c’est qu’il est possible de mettre en œuvre des techniques de programmation orientée objet en C. Cela est notamment utilisé dans les bibliothèques graphiques comme (Motif, LessTif ou GTK+), pour gérer leurs éléments : une fenêtre ou un bouton sera géré simplement comme un widget générique par moments.
Je vais expliquer le principe de ce genre de techniques, sachant que cela peut aller bien plus loin que ce que je vais vous montrer.

Continuer la lecture de « Les langages de programmation – Partie 2 : Le modèle objet »

Les langages de programmation – Partie 1 : Ce que je connais

Régulièrement (enfin, disons tous les 3/4 ans) je me pose des questions existentielles au sujet des langages de programmation. Pourquoi est-ce que j’aime tel langage, pourquoi je déteste tel autre, qu’est-ce que je pourrais vouloir et que je n’ai pas, et ainsi de suite…

Ne me demandez pas pourquoi, mais ça me reprend en ce moment. Ça va sûrement repartir aussi vite que c’est venu, mais ça amène quand même quelques réflexions.

Je pense écrire 3 articles sur le sujet. Dans celui-ci, je vais lister les langages que je connais, histoire de situer un peu les choses. Dans le suivant, je parlerai un peu du modèle objet sous un angle inhabituel. Pour terminer, je « réfléchirai à haute voix » sur ce que j’attends d’un langage de programmation, et pourquoi je serai toujours un éternel insatisfait.

BASIC

C’est le premier langage que j’ai appris. Quand j’étais gamin, dans les années 80, il y avait deux émissions télévisées au Québec − Octo-puce et Octo-giciel − qui enseignaient entre autre à programmer en Basic. C’est comme ça que j’ai commencé à programmer sur papier en rêvant au jour où j’aurais un ordinateur. Environ 10 ans plus tard, j’ai passé un couple d’années à programmer en Visual Basic ; c’était avant de commencer mes études d’informatique, et je croyais savoir programmer…

Ce que j’en retiens, c’est que le Basic, le « vrai » (celui des Apple II et Commodore 64) était en fait complètement imbitable. Après coup, j’ai compris en partie pourquoi Dijkstra avait la dent si dure à son encontre.
Malgré tout, ses déclinaisons successives, depuis le QuickBasic, les STOS et AMOS, jusqu’au RealBasic et le VB.NET, en ont fait un langage moderne et utilisable.

Moderne et utilisable, mais je n’ai désormais strictement aucune envie de coder en Basic.

Javascript

Je me suis intéressé au Web dès 1995. Je me suis mis alors au HTML, et même à cette époque cela incitait à rapidement se pencher sur le Javascript. Les premières années, je n’en ai fait qu’un survol, mais j’ai fini par mettre en œuvre des techniques assez poussées (notamment concernant la programmation orientée objet en Javascript) qui me sont encore utiles aujourd’hui au quotidien. Je suis même passé par une phase de développement assez intensive à base de XUL, où tout le code est réalisé en Javascript.

À une époque, j’étais assez fan du Javascript. J’aimais sa simplicité et sa malléabilité. J’ai imaginé l’utiliser pour des usages très divers. Pour les développements « client lourd », après avoir développé en XUL, j’en suis un peu revenu ; comme expliqué dans un précédent article, je me suis fatigué de devoir taper 8 lignes de code illisible pour simplement lire le contenu d’un fichier. Pareil pour les développements côté serveur ; j’ai longtemps pensé que le Javascript combinait assez de qualités pour s’y montrer à son avantage ; cette idée va et vient, depuis le serveur de Netscape dans les années 90, jusqu’à  des projets comme CommonJS et Node.js.
J’espère que Mathieu ne m’en voudra pas, mais l’ensemble du langage me paraît maintenant trop bancal pour sortir de l’usage Web client qui est sa spécialité. Entre le modèle objet incomplet, la bibliothèque standard plutôt limitée et une évolution très lente (qui ne laisse pas apercevoir d’améliorations profondes à courte échéance), je préférerai toujours d’autres solutions.

C

Ce fut la grande révélation de ma vie. Ce que j’apprécie dans ce langage, c’est sa simplicité et sa limpidité. Quelques types scalaires, des structures (et des énumérations et des unions), des fonctions… et des pointeurs au milieu de tout ça. Difficile de faire plus évident. J’ai acquis une certaine expertise en C ; durant mes études j’ai fait du développement kernel (Linux et BSD), et par la suite j’ai travaillé dans le développement système et réseau. C’est formateur.

On entend souvent dire que le C n’est qu’un assembleur à peine amélioré… C’est tellement faux ! Par contre, ce qui est certain, c’est qu’il est quasi-impossible de faire des exécutables plus rapides et plus petits que ceux écrits en C. Bon, il n’est évidemment pas exempt de défauts, mais qui sont inhérents à ce qu’il est intrinsèquement. Si vous savez ce que vous faites, le C est un outil redoutable ; par contre, si vous vous permettez des approximations, vous ne vous en relèverez pas.

Continuer la lecture de « Les langages de programmation – Partie 1 : Ce que je connais »