Question

J'ai lu qu'au lieu d'écrire simplement un tas de fonctions, je devrais utiliser un littéral d'objet.

Quelqu'un peut-il expliquer les avantages de l'objet littéral à l'aide d'exemples, car je ne comprends pas jusqu'à présent.

Merci

Était-ce utile?

La solution

Comme Russ Cam l'a dit, vous évitez de polluer l'espace de noms global, ce qui est très important en ces temps de combinaison de scripts provenant de plusieurs emplacements (TinyMCE, etc.).

Comme Alex Sexton l’a dit, cela permet également une bonne organisation du code.

Si vous utilisez cette technique, je vous conseillerais d'utiliser le modèle de module. Ceci utilise toujours les littéraux d'objet, mais comme valeur de retour d'une fonction de portée:

var MyThingy = (function() {

    function doSomethingCool() {
        ...
    }

    function internalSomething() {
        ....
    }

    function anotherNiftyThing() {
        // Note that within the scoping function, functions can
        // call each other direct.
        doSomethingCool();
        internalSomething();
    }

    return {
        doSomethingCool: doSomethingCool,
        anotherNiftyThing: anotherNiftyThing
    };
})();

Utilisation externe:

MyThingy.doSomethingCool();

La fonction de cadrage englobe toutes vos fonctions, puis vous l'appelez immédiatement et stockez sa valeur de retour. Avantages:

  • Les fonctions sont déclarées normalement et ont donc noms . (Tandis que, avec le format {name: function () {...}} , toutes vos fonctions sont anonymes, même si les propriétés les référençant ont un nom.) Les outils d'aide sur les noms vous aident à afficher appeler des piles dans un débogueur, pour vous dire quelle fonction a jeté une exception. (Mise à jour 2015: la dernière spécification JavaScript, ECMAScript 6ème édition, définit un grand nombre de manières pour le moteur JavaScript d’indiquer le nom d’une fonction. Un de ceux-ci est le cas lorsque la fonction est affectée à une propriété, comme dans notre {name: function () {...}} exemple. Ainsi, à mesure que les moteurs implémenteront ES6, cette raison disparaîtra.)
  • vous donne la liberté de n'utiliser que des fonctions privées utilisées par votre module (tel que mon internalSomething ci-dessus). Aucun autre code sur la page ne peut appeler ces fonctions; ils sont vraiment privés. Seuls ceux que vous exportez à la fin, dans l'instruction return, sont visibles en dehors de la fonction d'étendue.
  • Facilite le retour de différentes fonctions en fonction de l’environnement, si l’implémentation ne fait que changer complètement (comme les éléments IE-vs-W3C, SVG ou Canvas, etc.).

Exemple de renvoi de différentes fonctions:

var MyUtils = (function() {
    function hookViaAttach(element, eventName, handler) {
        element.attachEvent('on' + eventName, handler);
    }

    function hookViaListener(element, eventName, handler) {
        element.addEventListener(eventName, handler, false);
    }

    return {
        hook: window.attachEvent ? hookViaAttach : hookViaListener
    };
})();

MyUtils.hook(document.getElementById('foo'), 'click', /* handler goes here */);

Autres conseils

L'utilisation d'un littéral d'objet (un motif littéral d'objet.a.k.) ne polluera pas autant l'espace de noms global que l'utilisation de nombreuses fonctions déclarées globalement, et permet également d'organiser le code de manière logique

Par exemple, cet objet littéral

var obj = {
              find : function(elem) { /* find code */ },
              doSomething: function() { /* doSomething code */ },
              doSomethingElse: function() { /* doSomethingElse code */ }
          }

par rapport à

function find(elem) { /* find code */ },
function doSomething() { /* doSomething code */ },
function doSomethingElse() { /* doSomethingElse code */ }

ne créera qu'une seule propriété sur l'objet global contre trois. Vous pouvez ensuite utiliser facilement les fonctions telles que

obj.doSomething();

Rebecca Murphey a fait une conférence sur les littéraux objets lors de la conférence jQuery de cette année. Une des meilleures raisons de les utiliser est simplement une bonne organisation du code.

Voici le récit de Rebecca sur le modèle d'objet littéral: http://rmurphey.com/blog/2009/10/15/using-objects-to-organize-your-code/

J'ai toujours utilisé des littéraux d'objet car ils constituent un moyen clair d'organiser le code. C’est pourquoi je n’aime pas les prototypes, c’est trop salissant.

Les fonctions ne modifient pas l’espace de noms comme mentionné ci-dessus, pas plus que les littéraux d’objet.

Vous pouvez facilement écrire un littéral tel que

var obj = {}
var find = function(elem) { /* find code */ },
var doSomething = function() { /* doSomething code */ },
var doSomethingElse = function() { /* doSomethingElse code */ }

qui poluterait en créant beaucoup d’objets globaux identiques aux fonctions. De même, vous pourriez faire:

(function() {
function find(elem) { /* find code */ },
function doSomething() { /* doSomething code */ },
function doSomethingElse() { /* doSomethingElse code */ }
})();

qui ne créerait pas ces objets globaux (tout est un objet dans JS)

Ainsi, vous ne créez toujours pas de charges d'objets globaux.

Pour moi, les littéraux d'objet ont deux avantages. Une fois qu’ils sont utilisés par de nombreux plugins tels que jQuery, les gens sont plus familiers et faciles à lire. Ce qui les rend faciles à transmettre des données dans un plugin. Il est facile de créer des méthodes publiques et privées ....

Elles peuvent être lentes car chaque fois que vous créez une instance de l’objet, toutes ses méthodes sont dupliquées. Je crois comprendre que ce n’est pas le cas avec prototype, car vous n’avez qu’une copie des méthodes et les nouveaux objets ne font que référencer le prototype.

Je peux me tromper bien sûr ...

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top