Go에서 임베디드 유형을 사용하는 String() 메서드의 모호한 동작
Go에서 임베디드 유형을 다룰 때 String의 동작 이해 () 방법은 혼란스러울 수 있습니다. 특정 코드 샘플을 기반으로 이 동작을 자세히 살펴보겠습니다.
다음 코드를 고려하세요.
type Engineer struct { Person TaxPayer Specialization string } type Person struct { Name string Age int } func (p Person) String() string { return fmt.Sprintf("name: %s, age: %d", p.Name, p.Age) } type TaxPayer struct { TaxBracket int } func (t TaxPayer) String() string { return fmt.Sprintf("%d", t.TaxBracket) } func main() { engineer := Engineer{ Person: Person{ Name: "John Doe", Age: 35, }, TaxPayer: TaxPayer{3}, Specialization: "Construction", } fmt.Println(engineer) }
이 코드의 출력은 다음과 같습니다.
{name: John Doe, age: 35 3 Construction}
그러나 Person.String()이 제거되면 출력은 다음과 같습니다.
3
그리고 if TaxPayer.String()도 제거되고 출력은 다음과 같이 변경됩니다.
{{John Doe 35} {3} Construction}
처음에는 Engineer 구조체에 대한 암시적 String() 메서드가 있어야 하는 것 같습니다. 그러나 그렇지 않습니다.
임베디드 유형의 String() 메서드
유형이 구조체 내에 삽입되면 해당 필드와 메서드는 다음을 통해 액세스할 수 있습니다. 삽입형. 이러한 메소드 "승격"은 여러 내장 유형이 String()과 같은 동일한 이름의 메소드를 정의하는 경우 모호성을 초래할 수 있습니다.
주어진 코드 샘플에서는 Person과 TaxPayer 모두 String()을 갖기 때문에 메서드를 엔지니어 유형으로 승격하면 모호함이 발생합니다. 이것이 Engineer.String()에서 컴파일 오류가 발생하는 이유입니다.
fmt.Println()을 사용할 때 모호성 오류가 발생하지 않는 이유
엔지니어의 메소드 세트의 모호함에도 불구하고 , fmt.Println(엔지니어)는 컴파일 오류를 발생시키지 않습니다. 이는 fmt.Println()이 fmt.Fprint(os.Stdout, Engineer)를 호출하기 때문입니다.
fmt.Fprint()는 전달된 값이 String() 메서드를 포함하는 fmt.Stringer 인터페이스를 구현하는지 확인합니다. . 그렇다면 String()을 사용하여 값의 문자열 표현을 생성합니다.
이 경우 Person과 TaxPayer 모두 fmt.Stringer를 구현하지 않으므로 기본 형식(구조체 필드)이 대신 사용됩니다. 그러면 fmt.Println(engineer)이 호출될 때 표시되는 출력이 생성됩니다.
결론
내장 유형의 동작을 이해하고 해당 메서드를 홍보하는 것이 중요합니다. 이동 중. 여러 개의 포함된 유형이 동일한 이름의 메서드를 정의하면 모호성이 발생하여 컴파일 오류가 발생할 수 있습니다. 그러나 fmt.Println()을 사용할 때 전달된 값이 fmt.Stringer를 구현하지 않는 경우 기본 형식이 사용됩니다.
위 내용은 임베디드 유형에 충돌하는 `String()` 메소드가 있을 때 `fmt.Println()`이 Go의 임베디드 유형과 다르게 동작하는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!