Discussion :

[Bovino]

Jean-Pierre Vincent vous propose un article de présentation sur la Programmation Orientée Objet en JavaScript.
Javascript Orienté Objet : syntaxe de base des classes JavaScript à l'intention des développeurs PHP

Ce tutoriel a pour cible les développeurs qui ont une expérience du PHP (5) et qui veulent se lancer dans un projet JavaScript qui dépasse le simple scripting. Cela va donc commencer par savoir écrire des classes en JavaScript. Pour avoir galéré en tant que développeur puis en tant que lead technique, avoir formé de bons développeurs PHP à faire des applications Web où le JavaScript représente plus d'un tiers du code et la moitié du temps de développement, j'ai pu constater les énervements classiques lorsqu'on commence à vouloir faire des choses sérieuses en JavaScript.
Le but ici n'est pas de rentrer dans la théorie du langage JavaScript ou même d'être exhaustif (voir à la fin de cet article des ressources qui le font très bien), mais de vous fournir un template pour commencer à écrire vos classes.

Merci de faire part de vos commentaires, remarques et encouragements pour cet article dont l'approche permettra, je l'espère, de faire comprendre que le modèle orienté objet par prototype est aussi valable que le modèle plus classique de classes et d'héritage.

Bonne lecture à tous et à l'auteur !

PS : Si vous souhaitez voter pour ce message, faites-le plutôt sur le message de jpvincent qui est l'auteur de l'article

[vermine]

Article très intéressant. Bouts de codes à l'appui, ce qui permet de bien appréhender la transition du PhP vers le Javascript.
Merci pour cette démarche instructive.

[camus3]

bon article , même si je déteste javascript. Non pas à cause du prototypage, mais parce que le développeur n'a pas le choix de la techno cliente finalement.
J'image ce qui aurait pu être le web si ruby ou python s'étaient imposé coté client. ECMA a fait un sale boulot, et il est trop tard pour changer quoi que ce soit , bref , les devs sont "coincés" avec javascript.
Néanmoins les closures et les lambdas sont l'aspect le plus puissant de javascript.

[Bisûnûrs]

Petite coquille dans le code PHP de la section "Classes statiques" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
static function isMailValid($sMail) {
   return (preg_match("/".self::$regMail."/", $sMail) === 1) ;
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

print MY_APP_NAMESPACE\validation::isValidMail( 'mon@mail.com' );

De plus (mais ça n'entrave rien à la bonne marche de l'article), pour cette méthode on aurait pu utiliser filter_var() au lieu d'une expression régulière.

[psychomatt]

Merci pour cet article très intéressant.
Et j'en profite pour glisser que "oui je suis intéressé par la notion d'héritage en JS".

[arcanis]

Je pense que ça rentre dans le thème de l'article : j'ai fait il y a quelques temps un script permettant de gérer les classes Javascript en simulant le véritable concept des objets (public, protected, private, extends).

Ce n'est évidemment pas un script à utiliser en production (quoique si vous êtes un fanatique pur et dur ...), mais je le trouve assez intéressant en tant que proof of concept de ce qu'est capable d'accomplir le JS en matière d'objets.

http://arcanis.alwaysdata.net/classjs/class.js
http://arcanis.alwaysdata.net/classj...testsuite.html

Par ailleurs, en ce qui concerne les performances, un constat est réellement surprenant (et si quelqu'un découvre une erreur dans ma façon de compter, qu'il n'hésite pas, ça m'intéresse !) : il semblerait que, selon les navigateurs :
- IE 7 : Ne fonctionne pas, je n'ai pas cherché à le rendre compatible.
- Firefox : Environ 3x plus lent d'instancier un objet utilisant ma classe qu'un objet classique
- Chrome : Ca se vaut, avec un léger avantage pour un objet classique
- Opera : Donc là c'est le wtf : il est (semble-t-il) plus rapide d'instancier un objet de ma classe qu'un objet classique. Etrange, n'est-ce pas ?

[grunk]

Ca tombe pile au moment ou je dois développer une appli ou le JS sera dominant par rapport au reste !

Cela aurait pu être intéressant d'avoir un paragraphe sur les possibilité qu'apporte chaque framewok pour la réalisation de class.

[Bovino]

Petite coquille dans le code PHP de la section "Classes statiques" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
static function isMailValid($sMail) {
   return (preg_match("/".self::$regMail."/", $sMail) === 1) ;
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

print MY_APP_NAMESPACE\validation::isValidMail( 'mon@mail.com' );

De plus (mais ça n'entrave rien à la bonne marche de l'article), pour cette méthode on aurait pu utiliser filter_var() au lieu d'une expression régulière.

Ca a été rectifié.

[kimjoa]

très bonne articles !!

Il y a là toutes les bonnes techniques à adopter en js.... espace de nom, créer des variables local "ou privé", via des fonctions anonymes auto-exécuté...

C'est très bien

Des petites remarque quand même !!

Sur la sections des closures et variables privée.
Etant dans un context POO, votre exemple est pas vraiment valable, car il retourne un objet anonyme, et non rattaché à une classe.
Pour permettre des variables privé d'instance, il suffit de redéfinir les méthodes dans le constructeur.

du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
function MaClasse(){
    var argPrivé = "ok";
    this.funtionPublic = function(){
         return argPrivé;
   }
}

Mais c'est à éviter , comme vous l'avez précisé...

Sinon je trouve pas le lien -> contre performance des variables privées