알 수 없는 인터페이스를 사용하여 Go에서 유형 어설션을 어떻게 수행할 수 있습니까?

알 수 없는 인터페이스에 대한 Go의 유형 어설션

리플렉션을 통해 객체의 값을 검색하고 유형 어설션을 수행하여 다음을 사용하여 실제 객체를 얻는 프로세스입니다.

obj := new(User)
out := reflect.ValueOf(obj).Elem().Interface().(User)
fmt.Println(out == *obj) // true

과 같은 방법이 잘 알려져 있습니다. 그러나 객체 유형을 미리 알 수 없으면 문제가 발생합니다. 알 수 없는 인터페이스를 허용하는 함수를 생각해 보세요.

func Foo(obj interface{}) bool {
    // out := reflect.ValueOf(obj).Elem().Interface().( ... )
    return out == *obj
}

func main() {
    obj := new(User)
    fmt.Println(Foo(obj))
}

Foo 함수에서는 전달되는 객체의 유형을 결정하는 것이 불가능합니다. 이는 다음과 같은 질문을 제기합니다. 이러한 시나리오에서 유형 어설션을 어떻게 수행할 수 있습니까?

답은 유형 어설션의 특성에 있습니다. 유형 어설션을 사용하면 유형을 정적으로 확인할 수 없는 인터페이스로 작업할 때에도 Go에서 정적 유형 검사를 활용할 수 있습니다. 이 기능은 다음 원칙에 따라 작동합니다.

정적으로 유형이 지정된 t 유형의 변수 s가 주어지면 컴파일러는 s가 항상 t 유형으로 유지되도록 보장합니다. s가 다른 유형으로 사용되면 컴파일을 거부합니다. 이는 설정된 보증을 위반하기 때문입니다.

이제 인터페이스 변수 i를 상상해 보세요. 해당 유형은 컴파일 타임에 알 수 없으므로 컴파일러는 i를 s에 할당해도 s가 t 유형이라는 보장이 깨지지 않는다고 보장할 수 없습니다. 유형 주장은 "유형이 일치하는지 런타임에 확인하고 일치하는 경우에만 할당을 수행합니다."라고 명시하여 이 문제를 극복합니다. 컴파일러는 유형이 호환되는 경우에만 할당이 발생하여 s 유형이 t라는 보장을 유지하므로 이 접근 방식을 승인합니다.

기본적으로 이는 런타임에 다음이 발생함을 의미합니다.

if (i has type t) {
    s = i
} else {
    s = t{} // Zero value of t
}

요청된 기능의 불가능성은 컴파일러가 검사를 수행할 유형을 알아야 하기 때문에 발생합니다. 이러한 지식이 없으면 s의 정적 유형을 결정할 수 없으므로 검증 프로세스가 불가능해집니다.

위 내용은 알 수 없는 인터페이스를 사용하여 Go에서 유형 어설션을 어떻게 수행할 수 있습니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!