Wiele argumentów a obiekt opcji

Tworząc funkcję JavaScript z wieloma argumentami, zawsze mam do czynienia z takim wyborem: przekazać listę argumentów vs. przekazać obiekt opcji.

Na przykład piszę funkcję do mapowania nodeList do tablicy:

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

Zamiast tego mógłbym użyć tego:

function map(options){
    ...
}

gdzie opcje to obiekt:

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

Który z nich jest zalecany? Czy istnieją wytyczne dotyczące tego, kiedy używać jednej, a kiedy drugiej?

[Aktualizacja] Wydaje się, że istnieje konsensus na rzecz obiektu opcji, więc chciałbym dodać komentarz: jednym z powodów, dla których kusiło mnie, aby użyć listy argumentów w moim przypadku, było zachowanie zgodne z JavaScriptem wbudowana metoda array.map.

Podobnie jak wiele innych, często wolę przekazywać funkcję options objectdo funkcji zamiast przekazywać długą listę parametrów, ale tak naprawdę zależy to od dokładnego kontekstu.

Używam czytelności kodu jako papierka lakmusowego.

Na przykład, jeśli mam to wywołanie funkcji:

checkStringLength(inputStr, 10);

Myślę, że kod jest całkiem czytelny tak, jak jest, a przekazywanie poszczególnych parametrów jest w porządku.

Z drugiej strony istnieją funkcje z takimi wywołaniami:

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

Całkowicie nieczytelne, chyba że zrobisz jakieś badania. Z drugiej strony ten kod dobrze się czyta:

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

To bardziej sztuka niż nauka, ale gdybym miał nazwać praktyczne zasady:

Użyj parametru opcji, jeśli:

• Masz więcej niż cztery parametry
• Dowolny z parametrów jest opcjonalny
• Musiałeś kiedykolwiek sprawdzić funkcję, aby dowiedzieć się, jakie parametry ona potrzebuje
• Jeśli ktoś kiedykolwiek spróbuje Cię udusić, krzycząc „ARRRRRG!”

Wiele argumentów dotyczy głównie parametrów obowiązkowych. Nie ma z nimi nic złego.

Jeśli masz opcjonalne parametry, sprawa się komplikuje. Jeśli jeden z nich polega na innych, tak że mają określoną kolejność (np. Czwarty potrzebuje trzeciego), nadal powinieneś używać wielu argumentów. Prawie wszystkie natywne metody EcmaScript i DOM działają w ten sposób. Dobrym przykładem jest openmetoda XMLHTTPrequests , w której ostatnie 3 argumenty są opcjonalne - reguła jest taka jak „bez hasła bez użytkownika” (zobacz także dokumentację MDN ).

Obiekty opcji są przydatne w dwóch przypadkach:

• Masz tak wiele parametrów, że robi się to mylące: „Nazewnictwo” Ci pomoże, nie musisz martwić się o ich kolejność (zwłaszcza jeśli mogą się zmienić)
• Masz opcjonalne parametry. Obiekty są bardzo elastyczne i bez żadnego porządkowania po prostu przekazujesz rzeczy, których potrzebujesz i nic więcej undefined.

W twoim przypadku polecam map(nodeList, callback, options). nodelisti callbacksą wymagane, pozostałe trzy argumenty pojawiają się tylko sporadycznie i mają rozsądne wartości domyślne.

Innym przykładem jest JSON.stringify. Możesz chcieć użyć spaceparametru bez przekazywania replacerfunkcji - wtedy musisz wywołać …, null, 4). Obiekt arguments mógłby być lepszy, chociaż nie jest tak naprawdę rozsądny dla tylko 2 parametrów.

Najlepszym rozwiązaniem będzie wykorzystanie podejścia „opcji jako obiektu”. Nie musisz martwić się o kolejność właściwości i jest większa elastyczność w przekazywaniu danych (na przykład parametry opcjonalne)

Utworzenie obiektu oznacza również, że opcje mogą być łatwo używane w wielu funkcjach:

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

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

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

Myślę, że jeśli tworzysz instancję lub wywołujesz metodę obiektu, chcesz użyć obiektu opcji. Jeśli jest to funkcja, która operuje tylko jednym lub dwoma parametrami i zwraca wartość, preferowana jest lista argumentów.

W niektórych przypadkach dobrze jest używać obu. Jeśli twoja funkcja ma jeden lub dwa wymagane parametry i kilka opcjonalnych, ustaw pierwsze dwa parametry jako wymagane, a trzeci jako opcjonalny skrót opcji.

Na twoim przykładzie zrobiłbym to map(nodeList, callback, options). Lista węzłów i wywołanie zwrotne są wymagane, dość łatwo jest stwierdzić, co się dzieje, po prostu odczytując wywołanie do niego i przypomina to istniejące funkcje mapy. Wszelkie inne opcje można przekazać jako opcjonalny trzeci parametr.

Twój komentarz do pytania:

w moim przykładzie ostatnie trzy są opcjonalne.

Więc dlaczego tego nie zrobić? (Uwaga: to jest dość surowy JavaScript. Zwykle używałbymdefault skrótu i ​​zaktualizowałbym go opcjami przekazanymi za pomocą Object.extend lub JQuery.extend lub podobnych ...)

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

Tak więc, ponieważ teraz jest o wiele bardziej oczywiste, co jest opcjonalne, a co nie, wszystkie z nich są prawidłowymi zastosowaniami funkcji:

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

Mogę się trochę spóźnić na imprezę z tą odpowiedzią, ale szukałem opinii innych programistów na ten temat i trafiłem na ten wątek.

Zdecydowanie nie zgadzam się z większością respondentów i opowiadam się za podejściem „wielu argumentów”. Moim głównym argumentem jest to, że zniechęca to innych anty-wzorców, takich jak „mutowanie i zwracanie obiektu param” lub „przekazywanie tego samego obiektu param innym funkcjom”. Pracowałem w bazach kodu, które w znacznym stopniu nadużywały tego anty-wzorca, a debugowanie kodu, który to robi, szybko staje się niemożliwe. Myślę, że jest to bardzo praktyczna reguła specyficzna dla JavaScript, ponieważ Javascript nie jest silnie wpisany na maszynie i pozwala na takie dowolnie zbudowane obiekty.

Osobiście uważam, że programiści powinni być jawni podczas wywoływania funkcji, unikać przekazywania nadmiarowych danych i unikać modyfikacji przez odniesienie. Nie chodzi o to, że ten wzorzec wyklucza pisanie zwięzłego, poprawnego kodu. Po prostu czuję, że dzięki temu twój projekt znacznie łatwiej wpadnie w złe praktyki programistyczne.

Rozważ następujący okropny kod:

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

Tego rodzaju nie tylko wymaga bardziej przejrzystej dokumentacji, aby określić zamiar, ale także pozostawia miejsce na niejasne błędy. Co zrobić, jeśli modyfikuje developer param1w bar()? Jak myślisz, ile czasu zajmie przeglądanie bazy kodów o wystarczającej wielkości, aby to złapać? Trzeba przyznać, że ten przykład jest nieco nieszczery, ponieważ zakłada, że ​​programiści już popełnili kilka anty-wzorców do tego momentu. Pokazuje jednak, jak przepuszczanie obiektów zawierających parametry stwarza większe pole do popełniania błędów i niejednoznaczności, wymagając większej sumienności i przestrzegania stałej poprawności.

Tylko moje dwa centy w tej sprawie!

To zależy.

Opierając się na moich obserwacjach dotyczących projektowania tych popularnych bibliotek, oto scenariusze, w których powinniśmy użyć obiektu opcji:

• Lista parametrów jest długa (> 4).
• Niektóre lub wszystkie parametry są opcjonalne i nie zależą od określonej kolejności.
• Lista parametrów może wzrosnąć w przyszłej aktualizacji API.
• API zostanie wywołane z innego kodu, a nazwa API nie jest wystarczająco jasna, aby określić znaczenie parametrów. Więc może potrzebować silnej nazwy parametru dla czytelności.

I scenariusze użycia listy parametrów:

• Lista parametrów jest krótka (<= 4).
• Wymagana jest większość lub wszystkie parametry.
• Parametry opcjonalne są w określonej kolejności. (tj. $ .get)
• Łatwo rozpoznać znaczenie parametrów według nazwy API.

Object jest bardziej preferowany, ponieważ jeśli przekazujesz obiekt, łatwo jest rozszerzyć liczbę właściwości w tych obiektach i nie musisz zwracać uwagi na kolejność, w jakiej argumenty zostały przekazane.

W przypadku funkcji, która zwykle używa wstępnie zdefiniowanych argumentów, lepiej użyć obiektu opcji. Odwrotnym przykładem będzie funkcja, która pobiera nieskończoną liczbę argumentów, na przykład: setCSS ({wysokość: 100}, {szerokość: 200}, {background: "# 000"}).

Przyjrzałbym się dużym projektom javascript.

Rzeczy takie jak mapa google często stwierdzają, że tworzone obiekty wymagają obiektu, ale funkcje wymagają parametrów. Myślę, że ma to związek z argumentami OPCJI.

Jeśli potrzebujesz argumentów domyślnych lub opcjonalnych, obiekt prawdopodobnie byłby lepszy, ponieważ jest bardziej elastyczny. Ale jeśli nie masz normalnych funkcjonalnych argumentów, są bardziej wyraźne.

Javascript też ma argumentsobiekt. https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Functions_and_function_scope/arguments