JavaScript - Avantages de l'objet littéral

Question

J'ai lu que, plutôt que d'écrire simplement un tas de fonctions, je devrais utiliser des objets littéraux.

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

Merci

Answer 1

Comme l'a dit Russ Cam, vous évitez de polluer l'espace de noms global, ce qui est très important à notre époque où l'on combine des scripts provenant de plusieurs endroits (TinyMCE, etc.).

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

Si vous utilisez cette technique, je vous suggère d'utiliser le modèle de module. Celui-ci utilise toujours les littéraux d'objet, mais comme valeur de retour d'une fonction de cadrage :

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
    };
})();

Usage externe :

MyThingy.doSomethingCool();

La fonction de cadrage est enveloppée autour de 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 . (Alors qu'avec le {name: function() { ... }} toutes vos fonctions sont anonymes, même si les propriétés qui les référencent ont des noms). Les noms aident les outils à vous aider, qu'il s'agisse de montrer les piles d'appels dans un débogueur ou de vous dire quelle fonction a lancé une exception.
• Cela vous donne la liberté d'avoir des fonctions privées utilisées uniquement par votre module (comme mon module internalSomething ci-dessus). Aucun autre code de la page ne peut appeler ces fonctions ; elles sont vraiment privées. Seules celles que vous exportez à la fin, dans l'instruction de retour, sont visibles en dehors de la fonction de cadrage.
• Permet de renvoyer facilement des fonctions différentes en fonction de l'environnement, si l'implémentation change complètement (comme les trucs IE-vs-W3C, ou SVG vs. 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 */);

Answer 2

L'utilisation d'un littéral objet (aussi appelé motif de littéral objet) ne pollue pas l'espace de noms global comme le ferait 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, au lieu de trois. Vous pouvez alors facilement utiliser les fonctions comme suit

obj.doSomething();

Answer 3

Rebecca Murphey a présenté un exposé sur les littéraux d'objet lors de la conférence jQuery de cette année. L'une des meilleures raisons de les utiliser est tout simplement une bonne organisation du code.

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

Answer 4

J'ai toujours utilisé les littéraux d'objet parce qu'ils sont une manière claire d'organiser le code. C'est pourquoi je n'aime pas les prototypes, c'est trop désordonné.

Les fonctions ne polluent pas l'espace des noms, comme quelqu'un l'a mentionné plus haut, pas plus que les littéraux d'objets.

Vous pourriez facilement écrire un littéral comme

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

ce qui polluerait en créant beaucoup d'objets globaux identiques à ceux des fonctions. on pourrait faire de même :

(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 en JS).

de cette façon, vous ne créez toujours pas de charges d'objets globaux.

À mon avis, les littéraux d'objet ont deux avantages. D'une part, ils sont utilisés par de nombreux plugins tels que jQuery, donc les gens sont plus familiers et ils sont faciles à lire. Ce qui facilite le passage des données dans un plugin. Il est facile de créer des méthodes publiques et privées.....

Ils peuvent cependant être lents car à chaque fois que vous créez une instance de l'objet, toutes ses méthodes sont dupliquées. J'ai cru comprendre que ce n'était pas le cas avec le prototype, car vous n'avez qu'une seule copie des méthodes et les nouveaux objets font simplement référence au prototype.

Je peux me tromper bien sûr...