web-dev-qa-db-fra.com

Javascript - Fonction de stockage dans l'objet - mauvaise pratique?

Est-il considéré comme une mauvaise pratique de codage de stocker des fonctions dans un objet au lieu de simplement les définir (et donc globalement)?

Considérer:

1.

Foo = {
    bar: function() {
        alert("baz");
    }   
}

Foo.bar();

vs.

2.

function bar() {
    alert("baz");
}

bar();

Bien sûr, il pourrait être légèrement moins de code pour le deuxième exemple, mais lorsque vous commencez à obtenir beaucoup de fonctions - cela deviendra désordonné. Je le trouve moyen, moyen, plus propre, par exemple, d'utiliser Game.update() au lieu d'utiliser updateGame (); ou similaire. Lorsque vous approfondissez, comme Game.notify.admin(id) et ainsi de suite, cela vous donne un code encore plus joli.

Y a-t-il des inconvénients en stockant une fonction dans un objet?

javascriptfunctionobject
69
Zar

La première approche est préférée. De cette façon, vous définissez explicitement la portée de vos fonctions au lieu de polluer la portée globale. Il n'y a aucun inconvénient à utiliser la première approche. Seul avantage :-)

Conclusion: utilisez toujours la première approche pour définir les fonctions. Le second est comme le javascript dans les années 90, laissons le repos en paix dans le passé et utilisons un cadrage approprié.

68
Darin Dimitrov

Il n'y a pas de magie avec les objets d'espace de noms, et vous n'aurez pas nécessairement de problèmes si vous utilisez beaucoup de variables globales. La principale raison d'utiliser des objets "namespace" est de réduire le risque de noms de variables globales en double. Une deuxième raison est de regrouper des fonctions similaires pour plus de commodité, par exemple:

// Object example (suggested best practice):
// DOM functions are under myLib.dom
myLib.dom.someDOMFunction0;
myLib.dom.someDOMFunction1;

// Utility functions are under myLib.util
myLib.util.someUtilityFunction0;
myLib.util.someUtilityFunction1;

Notez que ce qui précède a pratiquement la même chance de doublons que les variables globales similaires:

// Global variable example:
myLib_dom_someDOMFunction0;
myLib_dom_someDOMFunction1;

myLib_util_someUtilityFunction0;
myLib_util_someUtilityFunction1;

Bien sûr, le premier est généralement préféré car il est considéré comme plus facile à travailler. Je ne préconise pas que vous adoptiez la deuxième approche (j'utilise la première), soulignant simplement que bien qu'il y ait un problème avec la création de nombreuses variables globales, la "pollution globale de l'espace de noms" est largement surestimée comme un danger.

4
RobG

Dans ce cas précis, choisissez le premier. Mais si votre objet Foo devient vraiment complexe, vous voudrez peut-être utiliser une autre approche qui vous donnera la possibilité d'utiliser un constructeur. Et la première approche n'est parfois pas la meilleure en ce qui concerne l'étendue de la fonction:

function Foo(appName){
    this.name = appName;      
}

Foo.prototype.Bar = function(){
   alert(this.name)
}

var a = new Foo("baz");
a.Bar();
3
Karl Mendes