Common lisp object system

Common Lisp Object System


WikiLettreMini.svg Cette page est considérée comme un article à approfondir.


Le Common Lisp Object System, souvent abrégé en CLOS (prononcé 'si-lauss'), est l'ensemble des primitives présentes dans le langage de programmation Common Lisp pour construire un programme orienté objet. Il existe également une version de CLOS pour le langage Scheme, nommée TinyClos.

Sommaire

Présentation

CLOS est un système objet à classes (il existe des systèmes à prototypes). Il descend de flavors et common loops, développés dans les années 1980. Common Lisp a été le premier langage à objet standardisé par l'ANSI, en 1995, précédant de peu SmallTalk.

Les objets et Lisp

D'un certain point de vue, Lisp est un langage orienté objet depuis le début : les structures de données manipulées ont une identité et sont réflexives. La seule chose qui lui manquait pour recevoir l'estampille orienté objet, est la capacité d'étendre le système de types de Lisp.

Caractéristiques

CLOS est construit autour de deux axes : les classes et les fonctions génériques.

Les classes de CLOS sont relativement similaires à celles des autres langages à objet. Ce sont des groups d'attributs. La spécialisation par héritage multiple est permise. Il est possible de définir des accesseurs et des mutateurs particuliers pour chaque attribut.

Contrairement à la plupart des systèmes à objets classiques, les méthodes ne sont pas définies dans l'espace de nom des classes. Elles appartiennent à des fonctions génériques, qui sont des objets distincts. Cela permet de réduire le couplage a priori entre types de données et opérations sur ces types. Cela autorise naturellement l'extension de la sélection dynamique de méthode à l'ensemble des arguments obligatoires, et non pas au premier paramètre privilégié (appelé généralement le 'receveur' de l'appel de méthode). Expliquons ces deux points.

Fonctions génériques

Des classes 'conteneurs' peuvent être définies dans des bibliothèques ou des frameworks indépendants, et cependant, certains concepts génériques s'appliquent à toutes ces classes : nombre d'éléments, représentation sérialisée pour en prendre deux. Ces concepts génériques sont, dans des langages comme Java ou C++, obligatoirement fournis par héritage (interface en Java, mixin en C++), pour satisfaire le système de types statique. Si les concepteurs ont oublié de fournir une interface pour une telle fonctionnalité générique, il n'y a rien à faire (en pratique, on doit contourner le problème par des procédés alourdissant le code, par exemple écrire ses propres sous-classes du framework disposant de la fonctionnalité voulue, mais ce n'est pas toujours possible). Des langages dynamiques comme Python, permettent le 'monkey-patching', c'est-à-dire l'ajout post-hoc de méthodes à des classes existantes; mais c'est une pratique découragée et posant des problèmes de maintenabilité.

La solution de CLOS à ce problème est la notion de fonction générique indépendante du site de définition et de l'espace de nom d'une classe associée. Ainsi on peut définir une fonction 'nb-elements' disposant d'implémentations (méthodes) variées pour des classes de provenances diverses sans avoir à toucher à la définition même de ces classes.

Sélection multiple

Puisque les méthodes sont groupées dans des fonctions génériques, il n'y a aucune raison de considérer que le premier argument est 'privilégié' (comme le 'self' ou 'this' d'autres langages à objets). On peut admettre des définitions de méthodes pour le tuple des types des arguments obligatoires.

Exemple avec des types numériques. L'opération d'addition, 'add' pourrait être définie classiquement comme ceci (en pseudo-code) :

class int:
    defmethod add(self, y):
        if isinstance(y, int):
            ...
        elif isinstance(y, float):
            ...

Avec juste deux types numériques int et float, il faut donc définir deux classes (int, float) et deux méthodes. De plus, chaque méthode contient un test de type sur le second argument. Cela pose un problème d'extensibilité. Si l'on veut ajouter de nouvelles méthodes, il faut disposer du source original. Si l'on veut ajouter de nouveaux types numériques (rationnels, complexes ou autres), nous ne pouvons facilement étendre les méthodes existantes (sans, à nouveau, accéder au source et ajouter des branches aux tests de types).

En dissociant classes et méthodes, on se permet donc d'ajouter après coup autant de classes que nécessaires, de définir des méthodes non prévues initialement, et finalement de fournir de nouvelles implémentations de méthodes (fonctions génériques en fait) après coup, de façon non intrusive.

class int: ...
class float: ...
defmethod add(x: int, y: int): ...
defmethod add(x: int, y: float): ...
defmethod add(x: float, y: int): ...
defmethod add(x: float, y: float): ...

Et après coup:

defmethod product(x: int, y: int): ...

(bien entendu il faut produire l'ensemble des combinaisons pertinentes pour le domaine d'application),

class rational: ...
defmethod add(x: int, y: rational): ...
  • Portail de la programmation informatique Portail de la programmation informatique
Ce document provient de « Common Lisp Object System ».

Wikimedia Foundation. 2010.

Contenu soumis à la licence CC-BY-SA. Source : Article Common lisp object system de Wikipédia en français (auteurs)

Regardez d'autres dictionnaires:

  • Common Lisp Object System — For other uses, see Clos (disambiguation). The Common Lisp Object System (CLOS) is the facility for object oriented programming which is part of ANSI Common Lisp. CLOS is a powerful dynamic object system which differs radically from the OOP… …   Wikipedia

  • Common Lisp Object System — Das Common Lisp Object System (kurz: CLOS) ist die objektorientierte Erweiterung der Programmiersprache Common Lisp. Es hat seine Ursprünge in Loops und Flavors, und ist im ANSI Standard für Common Lisp spezifiziert. CLOS wird (optional) durch… …   Deutsch Wikipedia

  • Common Lisp Object System — Cette page est considérée comme un article à approfondir. Le Common Lisp Object System, souvent abrégé en CLOS (prononcé si lauss ), est l ensemble des primitives présentes dans le langage de programmation Common Lisp pour construire un programme …   Wikipédia en Français

  • Common Lisp Object System — …   Википедия

  • Common Lisp Object System (disambiguation) — Common Lisp Object System may refer to: Common Lisp Object System Clos network This disambiguation page lists articles associated with the same title. If an internal link led you here, yo …   Wikipedia

  • Common Lisp — Paradigm(s) Multi paradigm: procedural, functional, object oriented, meta, reflective, generic Appeared in 1984, 1994 for ANSI Common Lisp Developer ANSI X3J13 committee Typing discipline …   Wikipedia

  • Common Lisp — est un langage fonctionnel impur de la famille Lisp. Sommaire 1 Introduction 2 Syntaxe 3 Types de données 3.1 Types scalaires …   Wikipédia en Français

  • Object-Oriented Programming in Common Lisp: A Programmer's Guide to CLOS — (1988, Addison Wesley, ISBN 0 201 17589 4) is a book by Sonya Keene on the Common Lisp Object System. Published first in 1988, the book starts out with the elements of CLOS and develops through the concepts of data abstraction with classes and… …   Wikipedia

  • Common Lisp the Language — is an influential book by Guy L. Steele about Common Lisp. Contents 1 History 1.1 Before standardization 1.2 During standardization 1.3 A …   Wikipedia

  • Common-Lisp — Inoffizielles Lisp Logo Basisdaten Paradigmen: multiparadigmatisch: funktional, prozedural …   Deutsch Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”