JavaScript et OO

Par Sébastien Pierre, dimanche 10 septembre 2006 à 17:55 :: Langages :: #37 :: rss

Tout le monde parle d'AJAX, Comet et plus généralement du Web 2.0. Une des pierres angulaire de ce nouveau type d'application est le langage JavaScript, qui grâce qu travail du W3C et de courageux pionniers, est en train de devenir un "vrai" langage de programmation (plutôt qu'une interface pour bidouille).

Cela dit, JavaScript est encore assez loin d'être le langage idéal pour le développement d'applications conséquentes. Un des problèmes principal est l'absence d"un mécanisme d'héritage autre que le modèle par prototypes (qui est incomplet, car le mot-clé super n'est pas encore implanté).

On trouve sur le wiki de Scriptaculous quelques implantations qui essaient de fournir des mécanismes d'héritage (simple), mais elles ne tiennent pas la route dès lors que l'on écrit une application conséquente (le problème récurrent étant leur implantation partielle ou non fiable d'un remplacement à super, qui tourne vite au cauchemard).

Voilà pourquoi j'ai décidé d'écrire ma propre librairie : Extend for Prototype. Elle permet de faire de l'héritage simple, de changer dynamique la hiérarchie de classes, et fournit de la méta-information indispensable au débugage, comme le nom de la class, les méthodes déclarées, les méthodes héritées,etc (ex:objet.getClass().className qui permet de connaître le nom de la classe d'une instance).

Donc si vous pratiquez JavaScript de manière intense, et que vous souhaitez passer à un développement robuste, je pense qu'Extend vous sera autant utile qu'à moi

Commentaires

1. Le mercredi 18 octobre 2006 à 15:48, par Damien

Intéressant... de mon côté je me demande justement si l'héritage est vraiment nécessaire
Quand on a les traits, il est très facile d'assembler le comportement des objets, et la hiérarchie des classes ne sert plus qu'à définir l'état (en ajoutant des variables d'intance en plus de celles de la superclasse).
Je ne connais pas bien javascript donc effectivement si il n'a pas super c'est ennuyeux. Mais à part ça qu'est-ce qui te motive à implémenter un système de classes par dessus les prototypes ? l'habitude, des réels besoins d'organisation du code ?

2. Le mercredi 18 octobre 2006 à 16:06, par Sébastien

L'héritage est toujours utile quand tu veux définir un comportement générique pour un objet. Par exemple, si tu veux développer une librairie de composants graphiques génériques (des "widgets"), tu définiras probablement deux classes de base: Widget et Container (qui étend Widget). Tous tes composants utiliseront les attributs et opérations définis de manière générale dans ces classes.

Aussi, ajouter une notion de "super classe" (classe parente), et de la rendre accessible au développeurs, permet d'ajouter très facilement la vérification de type du style "isinstance(objet,classe)".

Bref, cela peut paraître un peu technique, mais dès lors que l'on fait un peu attention à l'architecture, la notion d'héritage devient indispensable, car elle permet de "généraliser" et de "spécialiser" à volonté.

3. Le mercredi 18 octobre 2006 à 21:08, par Damien

"Bref, cela peut paraître un peu technique"
Non, ça va c'est mon domaine de recherche (mais je découvre les langages à prototypes

"L'héritage est toujours utile quand tu veux définir un comportement générique"
Avec les prototypes il y a un lookup dans les protos parents de chaque objet aussi. Dans ton exemple Container serait un clone de Widget avec des champs et méthodes supplémentaires, et toutes les instances seraient des clones soit de Widget soit de Container.

"isinstance(objet,classe)"
Ouh, c'est pas très objet comme manière de faire... et quoi qu'il en soit on doit bien pouvoir aller chercher parmi les protos parents si il n'y a pas celui qu'on cherche. La difficulté est peut-être de savoir quel objet est une "instance" et quel objet est un "modèle".

En fait je regarde la hiérarchie des classes et métaclasses en smalltalk, et je me dis, tout ça pour respecter le dicton "tout objet est instance d'une classe" alors qu'on s'en sort avec des prototypes et de la délégation...

4. Le jeudi 19 octobre 2006 à 00:43, par Sébastien

Ah, je vois que tu entames une discussion

Le problème des prototypes est qu'ils montrent assez vite leurs limites, malgré leur flexibilité. Prenons l'exemple de notre objet "Widget" (qui sert de prototype). Disons que "widget" a des attributs "x,y,w,h" et une méthode "setPosition" qui permet de modifier ces attributs.

Maintenant, introduisons un objet "Button" et nous assignons "Widget" comme son prototype. Par défaut "Button" est un objet vierge, donc sans aucun attribut.

Le problème, maintenant, est que si l'on appelle "setPosition" sur l'objet "Button", et que ce dernier ne définit pas les slots "x","y", "w" et "h", ceux-ci seront résolus dans le prototype, et par conséquent, ce sont les attributs du prototypes que l'on va modifier.

Il faut donc que lorsque l'on assigne "Widget" comme prototype de "Button", on prenne soin de définir les dits attributs. Dans certains langages (comme Io), il y a une méthode "clone", et c'est celle-ci que l'on utilise pour obtenir un objet "fils" d'un objet servant de prototype.

Il faut donc finalement passer par une fonction "constructrice", qui va prendre un objet et le préparer (l'initialiser) pour que les opérations définies dans le prototype (les méthodes) puissent opérer sans faire de dégats.

Bon, cet exemple n'est pas forcément vrai dans tous les langages prototypés, mais ayant fait pas mal de Io et de JavaScript, c'est quelque chose qui revient assez souvent : c'est vrai que les prototypes sont un concept plus général que les classes (on peut baser un modèle de classe sur des prototypes, mais difficilement l'inverse), mais en pratique, on en revient souvent à refaire un système de classe par dessus.

Si tu jettes un coup d'oeil à Scriptaculous, tu verras que les prototypes (avec une fonction de construction, appelée par le "new") suffisent. Mais dès que tu veux spécialiser un prototype défini, tu vas te heurter au problème des initialisations en cascades, qui va t'amener à la nécessité d'avoir quelque chose comme un "super" (je ne vais pas détailler ici)... finalement, tu vas te retrouver à re-définir un petit système de classe par dessus tout ça.

Donc en gros, les prototypes c'est très flexible, et ca te permet de construire tes propres opérations de spécialisation/généralisation... mais ça ne les remplace pas vraiment, car leur besoin se fait sentir dès que l'on pousse un peu les choses

Et pour le "isinstance(objet,classe)", c'est mon habitude de Python

5. Le jeudi 19 octobre 2006 à 02:48, par Damien

Hmm bon en effet si il faut se taper la redéfinition des slots pour toutes les instances, c'est moins drôle... ça m'étonne quand même, il faudrait que je teste (donc que je fixe le paquet macports de io qui n'installe que des .h et des libs )

Ah, et merci de confirmer mon impression de python >:]

6. Le mardi 17 août 2010 à 08:00, par prom dress

I posted your piece of writing 2 my myspace profile.

7. Le lundi 23 août 2010 à 08:11, par cosplay

This is a great opportunity for us,” said Paul Nobles, Founder and CEO of Wakesites. “Social networking and user generated content are two of the most important themes playing out online today. To be able to leverage those trends in a wake-oriented social media campaign aligns perfectly with our vision of creating a dynamic, online community of wake sports enthusiasts.”

8. Le mardi 24 août 2010 à 14:48, par timberland shoe company

Out timberland hiking boots windows, we drink in the passing scene of cars on nearby highways, of children timberland shoe company waving at a crossing, of cattle grazing on a distant timberland boots hillside, of smoke pouring from a power plant, of row upon row of corn and wheat, of flatlands and timberland wheat shoes valleys, of mountains and rolling classic 3 eye timberland boat hillsides, of city skylines and village halls.But uppermost in our black timberland boots minds is the final destination. www.timberland4you.co.uk/...