[Article] Dojo et la programmation orientée objet

[Bovino]

Frédéric Bouchery vous propose un article présentant les bases de la Programmation Orientée Objet en JavaScript et vous montre comment le Framework Dojo simplifie son utilisation.

Merci à lui pour cet excellent article.

Dojo et la programmation orientée objet

Bien entendu, n'hésitez pas à faire part de vos questions, commentaires, encouragements !

[FERDIKAM]

Article très intéressant surtout sur l'explication de la POO en javascript qu'on rencontre beaucoup dans les framework javascript.
Merci !

[vermine]

Je rejoins l'avis de FERDIKAM. Merci pour le travail.

[Jcpan]

Bonjour

Interessant comme article , tu devrais expliquer en quelques lignes ce que c'est Dojo ou bien mettre un lien vers la page Morvan

Encore Merci pour cet article

[kimjoa]

Cool comme article !! c'est vrai que dojo est le meilleur framework pour la gestion des classes. Mais comme j'aime bien titillé, je vais faire quelque reproche

toutes les propriétés que vous déclarerez dans prototype seront recopiées par clonage dans tous les objets créés sur ce modèle.

En faite non , l'interpréteur crée un nouvelle objet pour chaque instance, et cette objet est relié par une chaine d'autre objet que sont les prototypes. Lors de l'utilisation du mot clé "this", l'interpréteur va chercher d'abord dans l'objet d'instance et ensuite si il trouve rien, dans les chaines d'objet prototype.
Cette recherche est couteuse en temps d'exécution, mais c'est ce qui fait du javascript un langage hautement dynamique car on peux changer à tout moment les valeur des propriété des prototypes ascendant.

Y' a une erreur dans ton modèle d'héritage. Le code suivant est faux.

....Coordonnee3D.prototype = Coordonnee.prototype;

// On ajoute les nouvelles propriétés
Coordonnee3D.prototype.super = Coordonnee;
Coordonnee3D.prototype.z = 0....;

Si tu assigne à un prototype un autre prototype, tu lui assigne une référence, un pointeur. Du coup quand tu modifies le prototype de base , tu modifies aussi le prototype dérivé.
En faite il faux définir le prototype de la classe dérivé, par une instance d'une classe de base, ce qui initialise la chaine de prototype.
Un exemple , lors de l'interprétation du mot clé this dans la classe dérivé, l'interpréteur va chercher d'abord dans l'objet d'instance, si il touve rien, il va chercher dans l'objet prototype de la classe dérivé, si il trouve pas et étant donné que cette objet prototype est une instance qui possède lui aussi un prototype il va chercher dans l'objet prototype du prototype de l'objet ect ... jusqu'à' ce qu'il tombe sur le prototype d'Objet, dont tout les objet javascript descende.

Donc pour dériver une classe il faut lui assigner une instance de la classe de base dans son prototype. Le problème c'est que pour l'instancier (la classe de base) on doit passer par le constructeur qui peux initialiser des attributs d'instance et demander de fournir des arguments.
La solution pour éviter ces problèmes est qu'on assigne le prototype de la classe base dans le prototype d'une fonction vide , (qui ne prends ancun argument est ne mets à jour aucun attribut d'instance) .

Par du code on comprends mieux, surtout que c'est pas évident à expliquer :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
function maClasseDeBase(argumentDinstance){
    this.attributDinstance= argumentDinstance; //on ini un attibut d'instance
}
maClasseDeBase.prototype = {
    attributDePrototype = 'je suis un attribut de prototype '
};
 
//déclaration de la fonction vide permettant d'initialiser une instance sans attribut d'instance
 
function maClasseTemporaire(){}
maClasseTemporaire.prototype = maClasseDeBase.prototype;
 
//assignation de l'instance sans attribut d'instance dans le prototype de la classe dérivé
 
function maClasseDerive(){...}
maClasseDerive.prototype = new maClasseTemporaire();

A noter que c'est sur la chaine des prototype d'un objet que la fonction instanceOf ce base ....

Sinon concernant dojo, il implémente aussi les mixins à la ruby, qui sont une implémentation particulière de l'héritage multiple. De plus il aurait été intéressant de renseigner le fait que dojo initialise les constructeur des classe de bases automatiquement , comme en c.

[emmanuel.remy]

Salut,

@kimjoa: pour compléter tes remarques autour de dojo

Sinon concernant dojo, il implémente aussi les mixins à la ruby, qui sont une implémentation particulière de l'héritage multiple.

Dojo dispose effectivement de mixin; la chaine d'héritage est conforme à l'algorithme C3, celui utilisé notamment par Python et PERL (Python 2.3 est d'ailleurs présenté comme la référence en matière de doc C3 pour Dojo).

De plus il aurait été intéressant de renseigner le fait que dojo initialise les constructeur des classe de bases automatiquement

C'est ce que dit Frédéric:

En fait, Dojo va créer systématiquement un appel au constructeur hérité, en passant tous les paramètres du constructeur dérivé (dans le même ordre).

Enfin pour "compléter" cette très bonne initiation à la POO avec Dojo, notons pêle-mêle qu'avec Dojo il est aussi possible d'hériter d'une classe Javascript standard (sans qu'elle ait été déclarée avec un dojo.declare), de gérer manuellement la chaine d'héritage, de gérer le chainage des méthodes sous la forme d'AOP (before, after).

ERE

[frederic.bouchery]

Bonjour à tous,

J'ai enfin pu prendre le temps de mettre à jour l'article qui comportait en effet, une grossière erreur (merci kimjoa). Que pensez-vous de mon approche désormais ?

Je dois encore y ajouter une référence vers l'article de mon ami et ex-collègue Mikaël sur le "build" des JS pour Dojo.

Sinon concernant dojo, il implémente aussi les mixins à la ruby, qui sont une implémentation particulière de l'héritage multiple.

L'algorithme C3, implémenté par le mixin de Dojo, est destiné à résoudre les problèmes de hiérarchisation en cas de multi-héritage. Comme je ne suis pas un fan du multi-héritage, je n'avais pas trop l'intention d'en parler.

Frédéric