Arguments multiples vs objet options

Question

Lors de la création d'une fonction JavaScript avec plusieurs arguments, je suis toujours confronté à ce choix: passer d'une liste d'arguments contre passer un objet d'options.

Par exemple je suis en train d'écrire une fonction pour mapper une nodeList à un tableau:

function map(nodeList, callback, thisObject, fromIndex, toIndex){
    ...
}

Je pourrais utiliser cette:

function map(options){
    ...
}

lorsque des options est un objet:

options={
    nodeList:...,
    callback:...,
    thisObject:...,
    fromIndex:...,
    toIndex:...
}

Ce qui est recommandé? Existe-il des lignes directrices pour savoir quand utiliser l'un contre l'autre?

[Mise à jour] Il semble y avoir un consensus en faveur de l'objet options, donc je voudrais ajouter un commentaire: une des raisons pour lesquelles j'ai été tenté d'utiliser la liste d'arguments dans mon cas était d'avoir un comportement cohérent avec le JavaScript intégré dans la gamme.méthode map.

Answer 1

Comme beaucoup d'autres, je préfèrent souvent passer un options object à une fonction plutôt que de passer une longue liste de paramètres, mais cela dépend vraiment du contexte exact.

J'utilise la lisibilité du code comme le révélateur.

Par exemple, si j'ai cette appel de la fonction:

checkStringLength(inputStr, 10);

Je pense que le code est tout à fait lisible de la façon dont il est et que la transmission des paramètres individuels est tout simplement parfait.

D'autre part, il y a des fonctions d'appels, comme ceci:

initiateTransferProtocol("http", false, 150, 90, null, true, 18);

Complètement illisible, sauf si vous faites un peu de recherche. D'autre part, ce code se lit ainsi:

initiateTransferProtocol({
  "protocol": "http",
  "sync":      false,
  "delayBetweenRetries": 150,
  "randomVarianceBetweenRetries": 90,
  "retryCallback": null,
  "log": true,
  "maxRetries": 18
 });

Il est plus un art qu'une science, mais si je devais le nom de règles de base:

Utiliser un paramètre options si:

• Vous avez plus de quatre paramètres
• Tous les paramètres sont facultatifs
• Vous avez déjà eu à regarder jusqu'à la fonction à déterminer quels paramètres il faut
• Si quelqu'un essaie de vous étrangler en hurlant "ARRRRRG!"

Answer 2

Plusieurs arguments sont pour la plupart des paramètres obligatoires. Il n'y a rien de mal avec eux.

Si vous avez des paramètres facultatifs, cela devient compliqué. Si l'un d'eux s'appuie sur les autres, de sorte qu'ils ont un certain ordre (par exemple, le quatrième besoins à la troisième), vous devez tout de même utiliser plusieurs arguments. Presque tous les indigènes EcmaScript et DOM-méthodes de travail de ce genre. Un bon exemple est l' open méthode de XMLHTTPrequests, où les 3 derniers arguments sont facultatifs - la règle est comme "pas de mot de passe sans que l'utilisateur" (voir également le MDN docs).

Option objets utile dans deux cas:

• Vous avez tant de paramètres qu'il reçoit à confusion: Le "naming" va vous aider, vous n'avez pas à vous soucier de l'ordre d'entre eux (surtout si ils peuvent changer)
• Vous avez des paramètres facultatifs. Les objets sont très flexibles, et sans n'importe quel ordre que vous venez de passer les choses dont vous avez besoin et rien d'autre (ou undefineds).

Dans votre cas, je vous recommande map(nodeList, callback, options). nodelist et callback sont requis, les trois autres arguments viennent qu'occasionnellement et qui ont de bonnes valeurs par défaut.

Un autre exemple est - JSON.stringify. Vous pouvez utiliser l' space paramètre sans passer un replacer fonction - puis vous appelez …, null, 4). Un objet arguments auraient été mieux, même si ce n'est pas vraiment raisonnable pour seulement 2 paramètres.

Answer 3

Utiliser l'approche 'options en tant qu'objet' sera préférable. Vous n'avez pas à vous soucier de l'ordre des propriétés et il y a plus de flexibilité dans les données transmises (paramètres facultatifs par exemple)

Créer un objet signifie également que les options pourraient être facilement utilisées sur plusieurs fonctions:

 options={
    nodeList:...,
    callback:...,
    thisObject:...,
    fromIndex:...,
    toIndex:...
}

function1(options){
    alert(options.nodeList);
}

function2(options){
    alert(options.fromIndex);
}
 

Answer 4

Je pense que si vous êtes à l'instanciation d'une chose ou d'appeler une méthode d'un objet, vous souhaitez utiliser un objet d'options. Si c'est une fonction qui fonctionne sur un ou deux paramètres et renvoie une valeur, une liste d'arguments est préférable.

Dans certains cas, il est bon d'utiliser les deux. Si votre fonction a un ou deux paramètres obligatoires et un tas d'option, de faire les deux premiers paramètres requis, et le troisième en option options de hachage.

Dans votre exemple, je ferais map(nodeList, callback, options). Nodelist et de rappel sont nécessaires, il est assez facile de dire ce qui se passe juste par la lecture d'un appel à elle, et c'est comme carte existante fonctions. Toutes les autres options peuvent être passées en tant que troisième paramètre facultatif.

Answer 5

Il dépend.

Fonde sur mon observation sur les bibliothèques populaires de conception, voici les scénarios que nous devrions utiliser l'option objet:

• Le paramètre liste est longue (>4).
• Certains ou tous les paramètres sont optionnels et ne pas compter sur un certain ordre.
• La liste des paramètres pourrait croître à l'avenir de l'API de mise à jour.
• L'API sera appelé à d'autres le code et le nom de l'API n'est pas clair assez pour dire les paramètres "dans le sens". Il pourrait donc besoin d'une forte nom du paramètre pour des raisons de lisibilité.

Et des scénarios pour utiliser le paramètre de la liste:

• Liste des paramètres est court (<= 4).
• La plupart ou tous les paramètres sont nécessaires.
• Les paramètres facultatifs sont dans un certain ordre. (c'est à dire: $.get )
• Facile de dire les paramètres de sens par le nom de l'API.