Prototypes indigènes vs $ .extension ()

Au travail, nous utilisons jQuery. Peu de temps après que nous avons commencé à l'utiliser, j'ai vu qu'un couple de développeurs ajoutaient des fonctions dans un fichier jquery-extensions.js. À l'intérieur, j'ai trouvé un ensemble de méthodes ajoutées à $ qui correspondent essentiellement à des méthodes statiques sur jQuery. Voici quelques-uns:

 $.formatString(str, args) { ... } $.objectToArray(obj) { ... }

Etc. Aucun d'entre eux n'utilise quoi que ce soit à propos de jQuery . Cela m'a frappé comme étrange.

Finalement, nous avions besoin d'une fonction dans notre bibliothèque pour localiser les dates. Ma solution était de créer:

 Date.prototype.toLocaleDate = function() { ... } Date.parseLocalDate = function() { ... }

Peu de temps après, je reçois un développeur senior qui me demande ce que je pense que je fais. Il me dit que là où je travaille, nous ne créons pas de prototypes parce qu'ils sont mauvais. Les seules raisons pour lesquelles il a donné, c'est qu'ils sont fondamentalement des caractéristiques de langage médiocres parce qu'ils «peuvent être abusés» et qu'il est confus de voir des prototypes (par exemple, comment puis-je connaître la nouvelle Date (). ToLocaleDate () est un prototype et non ECMAScript natif ). En utilisant $.formatString(...) au lieu de "blah blah".formatString(...) , nous gardons clair que rien avec un $ ne fait pas partie du JavaScript natif.

Ces raisons semblent un peu stupides, mais j'ai offert un compromis afin qu'il n'aurait pas à se rappeler si une méthode était un prototype-préfixe le nom de la fonction prototype avec $ :

 String.prototype.$format = function() { ... } "blah blah".$format(...);

Cela a été rapidement rejeté et maintenant je dois ajouter ces fonctions $ .myPrototypeAsAFauxStaticMethodOnjQuery () partout.

Est-ce que je suis le seul à penser que cette pratique est stupide?

Le débat sur les prototypes autochtones est un peu fatigué, il y a des points valables des deux côtés, j'essaierai de les résumer en espérant qu'il soit utile de voir la grande image.

Contra Il n'y a pas besoin d'étendre les prototypes indigènes. Vous avez tout ce dont vous avez besoin.
Pro JS la bibliothèque standard est rare à l'extrême. Les tableaux et les chaînes manquent de nombreuses fonctionnalités essentielles.

Contra Utilisez des fonctions ou vos propres "espaces de noms".
Pro Méthodes comme foo.trim() sont beaucoup plus dans l'esprit de la langue que des fonctions comme org.blah.trim(foo) . Tout est un objet en javascript et laisse tomber ainsi.

Contra Native Les objets JS sont "réservés" pour les designers linguistiques. Nos méthodes peuvent annuler accidentellement les composants intégrés nouvellement ajoutés.
Pro Les objets ouverts sont une fonctionnalité exceptionnelle et il serait stupide de ne pas l'utiliser. Une nouvelle version de Javascript n'est pas quelque chose qui se passe tous les jours et les ajouts à la norme sont bien connus à l'avance.

Contra L'extension des prototypes natifs est source de confusion, car il n'y a pas de distinction entre nos méthodes et nos méthodes natives.
La bibliothèque standard pro JS est petite et bien documentée. Nous savons que les développeurs javascript devraient connaître les noms des méthodes natives.

Contra L'extension des prototypes peut entraîner des conflits d'espace de noms.
Pro Oui, mais cela peut se produire avec des fonctions globales ou des objets globaux bien connus (comme $ ).

Contra Les méthodes personnalisées sont énumérables.
Pro Oui, mais il y a une hasOwnProperty de rescousse. Enroulez-le dans votre propre fonction d'énumérateur et arrêtez d'utiliser des boucles crues pour for..in boucles avec des objets.

(Pas une vraie réponse, donc CW)

Les titres supérieurs sont souvent surévalués.
Il y a beaucoup de gens qui ne comprennent pas les héritages prototypiques.
Même si l'extension du prototype d'objets JavaScript natifs est légale, ne le faites pas. Vous courez le risque de s'affronter avec des frameworks.
Il n'est pas logique de détourner $ pour les fonctions d'utilité non-jQuery. Pourquoi ne pas utiliser l'espace de noms de l'entreprise? Si vous devez être concis, utilisez $$ etc.

Je pense que ce n'est pas stupide !, Mais c'est plus beau d'utiliser un prototype! Mais encore une fois, qui s'intéresse à la beauté? Votre code sera finalement effrayant et sucera . Mais s'il est bien documenté et cohérent, vous n'aurez jamais besoin de réfléchir à ces problèmes!