가변 인수 함수는 선택적 인수에 적절한 솔루션입니까?

Question

마지막 인수가 선택적 인 함수가있는 경우 ...을 사용하여 인수를 선택적으로 허용하거나 적절한 형식이 아닌 것으로 간주하는 것이 적절합니까?

예 : 너무 많은 인수가 전달 된 경우이 예에서

func Foo(s ...string) { 
    switch len(s) { 
     case 0: 
      fmt.Println("You didn't pass an argument") 
     case 1: 
      fallthrough 
     default: 
      fmt.Printf("You passed %s\n", s[0]) 
    } 
} 

Foo("bar")  // "You passed bar" 
Foo()    // "You didn't pass an argument" 
Foo("bar", "baz") // "You passed bar" 

, 난 상관 없어,하지만 필요할 때 나는 default: 경우에 그 처리 할 수있다.

Answer 1

나는 이것을 권장하지 않습니다. 선택적 인수를 전달하기 위해 가변 인자를 사용하는 (ab) 다른 문제가 있습니다. 그들 중 가장 중요한 것은 아마도 마지막 형태 인 arg ...T)이 하나의 유형만을 허용한다는 것입니다. 두 개 이상의 유형이있는 둘 이상의 선택적 매개 변수에 대해서는 ...interface{}을 사용할 수 있지만 불필요한 런타임 (un) 복싱 비용이 발생하고 컴파일 타임 유형 검사 (usefull)가 부족합니다.

반대의 또 다른 주장은 표준 라이브러리에서 어디서나 예제/선례를 찾을 수 없다는 것입니다. 표준 라이브러리에서는 비공식 Go 코딩 스타일 가이드로 간주됩니다.

Answer 2

프로젝트는이 같은 상황에있는 경우는, 모든 프로젝트 요구 사항에 따라 달라집니다의 후 선택적 인수 시설이 단지 이런 종류의 상황에 대해 제공되는 모든 나쁜 형태

없다.

Answer 3

당신은 정말 선택적 인수가 필요 경우 (당신은 이동의 다음 stdlib에서 볼 수 있듯이, 그것은 드문) 관용적 방법은 선택적 인수의 각 필드가있는 구조체를 정의하는 것입니다, 다음 발신자가 통과 할 수 그들이 채울 필드가있는 구조체 리터럴

일반적으로 하나 또는 두 개의 "선택적인"인수 일 때 대체 함수 나 방법을 제공하는 것이 더 일반적입니다.이 인수는 대부분 시간이어야합니다.

파이썬과 같은 언어의 선택적 인수는 함수와 메소드가 다른 누구보다도 기억할 수있는 인수가 될 때까지 API가 커지고 커질 때가 많다는 것을 의미합니다.

매개 변수의 다양한 조합에 대해 명시적인 함수와 메소드를 정의하도록 강요하면 API에 대해 더 많은 생각을해야하지만 장기적으로는 훨씬 더 유용하고 유지할 수 있습니다.