Que nous réserve l'après orienté-objet ?

Dans le numéro de mars-avril de la revue American Scientist, Brian Hayes dresse un panorama des grandes étapes du développement logiciel, depuis l'assembleur jusqu'à l'émergence dans les années 80 de l'Object Oriented Programming (OOP) en passant par les langages structurés dans les années 60 et 70, avant d'examiner les initiatives actuelles visant à combler les lacunes des paradigmes existants et préfigurant, peut-être, une nouvelle étape du développement.

AOP: programmation "orientée-aspect"
Pour Hayes, l'une des difficultés communes avec l'OOP réside dans la décomposition optimale en classes & objets d'un programme à modéliser. Des mécanismes comme l'héritage multiple permettent de contourner certaines difficultés, mais il existe des cas où cette solution n'est pas toujours optimale, affectant la conception du programme donc sa clarté et éventuellement, in fine, ses performances. En d'autres termes, quand un choix d'arborescence de classes doit être effectuée, et que ce choix implique une structure où certains noeuds fils ont plusieurs noeuds parents, l'approche objet peut, dans des configurations particulières, trouver ses limites.

Parmi les moyens de s'affranchir de ses dernières figurent l'Aspect Oriented Programming (AOP) qui vise à isoler certains "aspects" d'un programme, c'est-à-dire un caractère commun à un ensemble de classes déjà caractérisées par un élément fédérateur tiers plus structurant. Exemples donnés par Brian Hayes: l'aspect convexe ou non des pentagones, octogones, etc., lesquels dans une approche objet sont des sous-classes d'une classe "polygone"; l'aspect "mise à jour de l'affichage" d'un ensemble de figures subissant des transformations... Dans ce dernier exemple, plutôt que d'écrire le code gérant la mise à jour de l'affichage dans chaque méthode de chaque figure géométrique, on isole cet aspect en spécifiant à quelles occasions il doit être invoqué (soit, donc, lors de chaque appel à une méthode caractérisant une transformation géométrique).

Design patterns
Autre moyen de contourner certains problèmes récurrents de l'OOP, l'émergence des "design patterns". Il s'agit d'adopter une approche résolument pragmatique et absolument pas normative de la programmation, en proposant des modèles (pattern) décrivant les difficultés les plus courantes (par exemple quand un objet - prenons un fichier - et une collection d'objets multiples - il s'agira dans ce cas d'un répertoire de fichiers - doivent se voir assignés un statut identique).

Parmi les autres méthodologies isolées par Brian Hayes, on peut citer la "programmation générative", caractérisée par l'automatisation de la production de code à partir de spécifications écrites suivant une sémantique cohérente qui n'a pas besoin d'être spécifique à un langage ou un système; ou encore l'eXtreme Programming - déjà abordé dans nos colonnes.