다중 인수 대 옵션 개체

다중 인수 대 옵션 개체

여러 인수를 사용하여 JavaScript 함수를 만들 때 항상 이 선택에 직면합니다. 인수 목록을 전달할지 옵션 개체를 전달할지 여부입니다.

예를 들어 nodeList를 배열에 매핑하는 함수를 쓰고 있습니다.

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

대신 이것을 사용할 수 있습니다.

function map(options){
    ...
}

여기서 options는 객체입니다.

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

어떤 방법이 좋을까요?하나를 사용할 때와 다른 하나를 사용할 때의 가이드라인이 있습니까?

[갱신]Options 객체에 찬성하는 의견이 있는 것 같습니다.그래서 코멘트를 덧붙이고 싶습니다.내 경우 인수 목록을 사용하고 싶은 이유 중 하나는 JavaScript의 built in array.map 메서드와 일치하는 동작을 하기 위해서입니다.

처럼, 저는 '', '하다', '하다', '하다', '하다'의 합격을 합니다.options object긴 파라미터 목록을 전달하지 않고 함수로 변환하지만 실제로는 정확한 컨텍스트에 따라 달라집니다.

코드 가독성을 리트머스 테스트로 사용합니다.

예를 들어, 다음 함수를 호출하는 경우:

checkStringLength(inputStr, 10);

나는 그 코드가 있는 그대로 꽤 읽을 수 있고 개별 매개변수를 통과시키는 것은 괜찮다고 생각한다.

한편, 다음과 같은 콜을 사용하는 기능도 있습니다.

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

조사를 하지 않으면 전혀 읽을 수 없습니다.한편, 이 코드는 올바르게 읽힙니다.

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

과학이라기보다 예술에 가깝지만, 경험의 법칙을 대자면:

다음과 같은 경우 옵션 매개 변수를 사용합니다.

• 매개 변수가 4개 이상 있습니다.
• 모든 매개 변수는 옵션입니다.
• 어떤 매개변수가 필요한지 알아내기 위해 함수를 찾아봐야 했던 적이 있습니다.
• 누군가 "ARRRG!"라고 외치면서 목을 조르려고 하면요

다중 인수는 대부분 필수 파라미터에 대한 것입니다.아무 문제 없어요.

옵션 파라미터가 있으면 복잡해집니다.둘 중 하나가 다른 하나에 의존하여 특정 순서가 있는 경우(예: 네 번째가 세 번째가 필요함)에도 여러 인수를 사용해야 합니다.거의 모든 네이티브 EcmaScript 및 DOM 메서드는 다음과 같이 동작합니다.좋은 예로는 XMLHTTP 요구 방식을 들 수 있습니다.마지막 3개의 인수는 옵션입니다.규칙은 "사용자 없이 비밀번호 없음"과 같습니다(MDN 문서 참조).

옵션 오브젝트는 다음 두 가지 경우에 편리합니다.

• 파라미터가 너무 많아서 헷갈릴 수 있습니다.'이름 짓기'가 도움이 됩니다.순서는 신경 쓸 필요가 없습니다(특히 변경해도 상관없습니다).
• 옵션 파라미터가 있습니다.은 매우것(또는 필요 을 수 .undefined s)

같은 경우에는 제가 게 요.map(nodeList, callback, options)nodelist ★★★★★★★★★★★★★★★★★」callback필수입니다.다른 3개의 인수는 가끔만 입력되며 기본값이 적당합니다.

다른 예는 다음과 같습니다.space되지 않은 replacer- function을 .…, null, 4)인수 오브젝트는 2개의 파라미터에 대해서만 타당하지는 않지만 더 나을 수 있습니다.

객체로서의 옵션' 접근 방식을 사용하는 것이 가장 좋습니다.속성 순서를 걱정할 필요가 없으며 전달되는 데이터의 유연성이 향상됩니다(옵션 파라미터 등).

오브젝트를 작성하면 여러 기능에서 옵션을 쉽게 사용할 수 있습니다.

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

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

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

둘 다 쓰면 좋을 것 같아요.함수에 하나 또는 두 개의 필수 매개 변수와 여러 개의 선택적 매개 변수가 있는 경우 처음 두 개의 매개 변수는 필수이고 세 번째 매개 변수는 옵션 해시입니다.

를 들면,신의,,음, 음음음음음음음음음음 in in in in in in in in in in in in in in in.map(nodeList, callback, options)Nodelist와 콜백이 필요하며 호출을 읽는 것만으로 무슨 일이 일어나고 있는지 알 수 있으며 기존 지도 기능과 같습니다.다른 옵션은 옵션의 세 번째 파라미터로 전달할 수 있습니다.

이 답변은 파티에 조금 늦을지도 모릅니다만, 이 주제에 대해 다른 개발자의 의견을 찾다가 우연히 알게 되었습니다.

나는 대부분의 응답자들의 의견에 매우 반대하며, '복수 논쟁' 접근 방식을 지지한다.주요 논거는 "param 객체를 변환하고 반환한다"거나 "같은 param 객체를 다른 함수에 전달한다"와 같은 다른 안티 패턴을 권장하지 않는다는 것입니다.저는 이 안티패턴을 광범위하게 악용한 코드베이스를 연구해 왔습니다.이렇게 하는 디버깅은 곧 불가능하게 됩니다.Javascript는 강한 타입이 아니고, 이러한 임의의 구조 오브젝트를 허용하는 것이기 때문에, 이것은 매우 Javascript 특유의 경험칙이라고 생각합니다.

개발자는 함수를 호출할 때 명시적이어야 하며 중복 데이터를 전달하지 않아야 하며 참조에 의한 수정은 피해야 한다고 생각합니다.이 패턴으로 인해 간결하고 정확한 코드를 쓸 수 없는 것은 아닙니다.당신의 프로젝트가 나쁜 개발 관행에 빠지기 훨씬 쉽다고 느낄 뿐입니다.

다음과 같은 끔찍한 코드를 생각해 보십시오.

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

이러한 종류의 문서화는 의도를 명시하기 위해 보다 명확한 문서화가 필요할 뿐만 아니라 애매한 오류가 발생할 여지가 있습니다.개발자가 수정하면 어떻게 됩니까?param1…에.bar()충분한 크기의 코드 베이스를 조사하려면 얼마나 걸릴 것 같습니까?이 예는 개발자가 이미 몇 가지 안티 패턴을 커밋했다고 가정하기 때문에 약간 솔직하지 못한 예라고 할 수 있습니다.그러나 이는 매개 변수를 포함하는 물체를 통과하는 것이 오류와 모호함의 여지를 더 많이 허용하고, 더 많은 양의 양심성과 항상 정확성의 준수를 요구하는 방법을 보여줍니다.

그 문제에 대해서는 딱 두 마디만!

질문에 대한 코멘트:

이 예에서는 마지막 세 가지는 선택 사항입니다.

그럼 왜 이렇게 안 해?(주의: 이것은 상당히 원시 Javascript입니다. 보통 해시를 사용하고 오브젝트를 사용하여 전달된 옵션으로 업데이트합니다.확장 또는 JQuery.extend 또는 유사..)

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

이제 무엇이 옵션이고 무엇이 아닌지가 훨씬 더 명확해졌기 때문에, 이 기능들은 모두 유효하게 사용됩니다.

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

사정에 따라 다르겠지.

이러한 일반적인 라이브러리 설계에 대한 관찰을 바탕으로 옵션오브젝트를 사용해야 할 시나리오를 다음에 나타냅니다.

• 파라미터 리스트는 깁니다(>4).
• 일부 또는 모든 파라미터는 옵션이며 특정 순서에 의존하지 않습니다.
• 매개 변수 목록은 향후 API 업데이트에서 증가할 수 있습니다.
• API는 다른 코드에서 호출되며 API 이름이 명확하지 않아 파라미터의 의미를 알 수 없습니다.따라서 읽기 쉽도록 하려면 강력한 매개 변수 이름이 필요할 수 있습니다.

파라미터 목록을 사용하는 시나리오:

• 매개 변수 목록이 짧습니다(<= 4).
• 파라미터의 대부분 또는 전부가 필요합니다.
• 옵션 파라미터는 일정한 순서로 배열되어 있습니다.(예: $.get)
• API 이름으로 파라미터 의미를 쉽게 알 수 있습니다.

개체를 전달하면 해당 개체의 속성 수를 쉽게 확장할 수 있고 인수가 전달된 순서를 확인할 필요가 없기 때문에 개체가 더 좋습니다.

일반적으로 미리 정의된 인수를 사용하는 함수의 경우 옵션개체를 사용하는 것이 좋습니다.반대되는 예로는 setCSS({height:100}, {width:200}, {background:"#000"})와 같은 무한한 수의 인수를 얻는 함수 등이 있습니다.

대규모 Javascript 프로젝트를 보고 싶습니다.

구글 맵과 같은 경우 인스턴스화된 오브젝트는 오브젝트가 필요하지만 함수에는 파라미터가 필요하다는 것을 자주 볼 수 있습니다.OPTION argumnts와 관련이 있다고 생각합니다.

디폴트 인수 또는 옵션인수가 필요한 경우 오브젝트가 유연하기 때문에 오브젝트가 더 좋을 수 있습니다.그러나 정상적이지 않은 경우 기능적 인수는 보다 명확합니다.

에는 Javascript가 .★arguments오브젝트도 있습니다.https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Functions_and_function_scope/arguments

언급URL : https://stackoverflow.com/questions/12826977/multiple-arguments-vs-options-object