Plusieurs arguments contre objet d'options

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){
    ...
}

où les options est un objet:

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

Dont l'une est la méthode recommandée? 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.

La deuxième option vous donne les arguments nommés, ce qui est une bonne chose à mon avis.
Sont-ils facultatifs ou obligatoires arguments?
dans mon exemple, les trois derniers sont en option.
Parce que vos deux derniers arguments sont très similaires, si l'utilisateur est passé seulement l'un ou l'autre, tu n'avais jamais vraiment être en mesure de savoir qui était prévu. À cause de cela, vous seriez presque besoin d'arguments nommés. Mais je peux comprendre que vous voulez maintenir une API similaire à l'API native.
La modélisation d'après l'API native n'est pas une mauvaise chose, si votre fonction fait la même chose. Il s'agit de "ce qui rend le code plus readablae." Array.prototype.map a une API simple qui ne devrait pas laisser un semi-connu codeur déconcertant plus.

InformationsquelleAutor Christophe | 2012-10-10

147

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.

- Je utiliser 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 passage de 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 bien:
```
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!"
- Grande réponse. Il dépend. Méfiez-vous boolean pièges ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html
- Oh oui... j'avais oublié le lien. Il m'a vraiment fait repenser l'Api de travail et j'ai même réécrit plusieurs morceaux de code après l'apprentissage, j'ai fait des choses stupides. Merci!
- Pas liées bien, mais qu'en est-il des langages tels que C#, où il y a des paramètres nommés et il pourrait ressembler à InitiateTransferProtocol(protocol: "http", sync: false, .... ?
- Jamais utilisé un langage avec des paramètres nommés, mais dans le concept, il avait l'air bien pour moi. Désolé.
- 'Vous avez déjà eu à regarder jusqu'à la fonction à déterminer quels paramètres il faut' - à l'Aide d'un objet d'options au lieu de cela, n'est-ce pas toujours avez à regarder la méthode pour comprendre que les touches sont nécessaires et ce qu'ils sont appelés. Intellisense dans l'IDE n'est pas la surface de cette info, alors que les params faire. Dans la plupart des IDEs, vous pouvez placez le pointeur de la souris sur la méthode et il va vous montrer ce que les params sont.
- Dépend de la langue et de l'environnement. Pas tout le monde utilise de plein IDEs. Pour ceux qui utilisent des IDEs, elles sont rarement JavaScript Intellisense droit. Visual Studio + Require.js par exemple, ne donne pas de soutien. Même au sein de VS, je trouve que le passage autour des objets de requête donne une meilleure lisibilité du code que d'avoir à passer sur quelque chose.
- Si y'all sont intéressés à la performance des conséquences de cette peu de "codage meilleures pratiques", voici un jsPerf test de deux façons: jsperf.com/function-boolean-arguments-vs-options-object/10 Notez le petit twist dans la troisième alternative, où j'utilise un "preset" (constant) options de l'objet, ce qui peut être fait lorsque vous avez de nombreux appels (au cours de la durée de vie de votre moteur d'exécution, par exemple, votre page web) avec les mêmes paramètres, connu au temps de développement (en abrégé: lorsque votre option valeurs sont un peu codé en dur dans votre code source).
- merci pour ce: "C'est plus un art qu'une science" et "j'utilise la lisibilité du code comme le révélateur." et "Si quelqu'un essaie de vous étrangler en hurlant "ARRRRRG!""
- initiateTransferProtocol("http", false, 150, 90, null, true, 18); Ah, le bon vieux " jours de Win32 et COM: CoCreateInstance(clsid, NULL, CLSCTX_INPROC_SERVER, IID_Isesoft, (void **)&pDispatch)
- Vous pouvez toujours tirer parti de ES6 arg déstructuration: initiateTransferProtocol({ protocole de synchronisation, ...reste }) { } Si vous allez avec l'objet d'options.
- Si cela est vrai, déstructuration n'existait pas lorsque la réponse a été écrit
- ouai j'ai regardé la date de 2015, j'adore la destruction et de l'utiliser tout le temps maintenant. Peut-être la réponse devrait refléter cette réalité?
- Le fait que les objets de travail à titre de référence vs copies jouer dans ce scénario, à tous?
- Honnêtement, je ne l'utilise plus ce style de codage à tous. J'ai basculé la Machine et d'utiliser des paramètres nommés.
InformationsquelleAutor Jeremy J Starcher
28

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 le ouvrir 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 aussi 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 nécessaires, 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 le space paramètre sans passer un replacer la fonction, alors vous devez appeler …, null, 4). Un objet arguments auraient été mieux, même si ce n'est pas vraiment raisonnable pour seulement 2 paramètres.
- +1 même question que @trevor-dixon: avez-vous vu ce mélange utilisé dans la pratique, par exemple dans les librairies js?
- Un exemple pourrait être de jQuery méthodes ajax. Ils acceptent l' [obligatoire] URL comme premier argument, et un énorme argument options que la seconde.
- tellement bizarre! Je n'ai jamais remarqué ça avant. J'ai toujours vu utilisé avec l'url comme une option de la propriété...
- Oui, jQuery fait des choses bizarres avec ses paramètres facultatifs, tout en restant compatible 🙂
- À mon avis, c'est le seul sain d'esprit de réponse ici.
InformationsquelleAutor Bergi
11

À l'aide de l'option "options comme un objet' approche va être meilleur. Vous n'avez pas à vous soucier de l'ordre des propriétés et il n'y a plus de flexibilité en ce que les données sont transmises (en option paramètres par exemple)

La création d'un objet signifie également les options pourrait facilement être utilisé sur de multiples fonctions:
```
options={
    nodeList:...,
    callback:...,
    thisObject:...,
    fromIndex:...,
    toIndex:...
}

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

function2(options){
    alert(options.fromIndex);
}
```
- +1 bon point sur la réutilisation des objets dans l'ensemble des fonctions.
- L' (raisonnable) hypothèse ici est que l'objet aura toujours les mêmes paires de clés. Si vous travaillez avec une merde/API contradictoire, alors vous avez un autre problème sur vos mains.
InformationsquelleAutor Fluidbyte
9

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.
- +1 je pense que c'est une bonne alternative équilibrée.
- +1 intéressant. Avez-vous vu qu'il est utilisé dans la pratique, par exemple dans les librairies js?
InformationsquelleAutor Trevor Dixon

Votre commentaire sur la question:

dans mon exemple, les trois derniers sont facultatifs.

Alors pourquoi ne pas le faire? (Note: C'est assez cru Javascript. Normalement, je voudrais utiliser un default de hachage et de mettre à jour avec les options passées en utilisant Objet.étendre ou JQuery.étendre ou similaire..)

function map(nodeList, callback, options) {
   options = options || {};
   var thisObject = options.thisObject || {};
   var fromIndex = options.fromIndex || 0;
   var toIndex = options.toIndex || 0;
}

Alors, maintenant, car il est maintenant beaucoup plus évident que ce qui est facultatif et n'est-ce pas, tous ces éléments sont valides utilisations de la fonction:

map(nodeList, callback);
map(nodeList, callback, {});
map(nodeList, callback, null);
map(nodeList, callback, {
   thisObject: {some: 'object'},
});
map(nodeList, callback, {
   toIndex: 100,
});
map(nodeList, callback, {
   thisObject: {some: 'object'},
   fromIndex: 0,
   toIndex: 100,
});

Ceci est similaire à @trevor-dixon réponse.

InformationsquelleAutor Izkata

3

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 de 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:
- Paramètre de la liste est courte (<= 4).
- La plupart ou tous les paramètres sont requis.
- 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.
InformationsquelleAutor Lynn Ning
2

Objet est plus préférable, parce que si vous passez un objet, il est facile d'étendre le nombre de propriétés des objets et que vous n'avez pas à regarder pour l'ordre dans lequel vos arguments a été adoptée.

InformationsquelleAutor happyCoda
2

J'ai peut-être un peu en retard à la fête avec cette réponse, mais j'étais à la recherche pour d'autres développeurs, les opinions sur ce sujet et suis tombé sur ce thread.

Je suis très en désaccord avec la plupart des intervenants, et à côté avec les multiples arguments' approche. Mon argument principal étant qu'elle décourage d'autres anti-modèles comme "la mutation et le retour de l'param objet", ou "passer la même param objet à d'autres fonctions". J'ai travaillé dans des bases de codes qui ont largement abusé de cet anti-modèle, et le débogage de code qui fait cela devient vite impossible. Je pense que c'est une très Javascript-règle particulière de pouce, car le Javascript n'est pas fortement typé et permet arbitrairement les objets structurés.

Mon opinion personnelle est que les développeurs doivent être explicite lors de l'appel de fonctions, éviter de passer des données redondantes et d'éviter de modifier par référence. Ce n'est pas que ce motif s'oppose à l'écriture concise, le code est correct. Je pense tout simplement que c'est beaucoup plus facile pour votre projet de tomber dans de mauvaises pratiques en matière de développement.

Envisager la suite de terribles code:
```
function main() {
    const x = foo({
        param1: "something",
        param2: "something else",
        param3: "more variables"
    });

    return x;
}

function foo(params) {
    params.param1 = "Something new";
    bar(params);
    return params;
}


function bar(params) {
    params.param2 = "Something else entirely";
    const y = baz(params);
    return params.param2;
}

function baz(params) {
    params.params3 = "Changed my mind";
    return params;
}
```
Non seulement ce genre d'exiger plus explicite de la documentation pour spécifier l'intention, mais il laisse aussi la place pour un vague des erreurs.
Que faire si un développeur modifie param1 dans bar()? Combien de temps pensez-vous qu'il prendrait en regardant à travers une base de code de sufficident taille pour attraper ce?
Certes, c'est l'exemple est un peu hypocrite car elle suppose que les développeurs ont déjà commis plusieurs anti-patrons par ce point. Mais elle montre comment le passage des objets contenant des paramètres permet une plus grande place à l'erreur et à l'ambiguïté, nécessitant un plus grand degré de conscience et de respect de const exactitude.

Juste mes deux cents sur la question!

InformationsquelleAutor ajxs
1

Pour une fonction qui utilise habituellement certains arguments prédéfinis vous permettrait de mieux utiliser l'option de l'objet. L'exemple ci-contre sera quelque chose comme une fonction qui est d'obtenir le nombre infini des arguments comme: setCSS({height:100},{largeur:200},{background:"#000"}).

InformationsquelleAutor Ilya Sidorovich
0

Je regarde les grands projets javascript.

Des choses comme google map, vous rencontrerez fréquemment que les objets instanciés besoin d'un objet, mais les fonctions requièrent des paramètres. Je pense que cela a à faire avec l'OPTION argumemnts.

Si vous avez besoin d'arguments par défaut ou en option arguments d'un objet serait probablement préférable car il est plus souple. Mais si vous n'avez pas fonctionnel normal arguments sont plus explicites.

Javascript a un arguments objet de trop.
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Functions_and_function_scope/arguments

InformationsquelleAutor dm03514

Vous devez vous connecter pour publier un commentaire.