Go 인터페이스에서 데이터를 정의하기 위해 임베디드 구조체를 사용해야 할까요?

Go 인터페이스 필드: 사용할 것인가, 사용하지 않을 것인가?

Go에서 인터페이스는 일반적으로 데이터보다는 기능을 정의하는 데 사용됩니다. 즉, 인터페이스에서 메소드를 지정할 수 있지만 구현에서는 필수 필드를 지정할 수 없습니다.

그러나 임베디드 구조체를 사용하면 메소드를 통해 데이터를 노출하여 효과적으로 정의하는 인터페이스를 생성할 수 있습니다.

예:

다음 예를 고려해보세요.

type PersonProvider interface {
    GetPerson() *Person
}

type Person struct {
    Name string
    Age  int64
}

func (p *Person) GetPerson() *Person {
    return p
}

type Bob struct {
    FavoriteNumber int64
    Person
}

In 이 예에서 PersonProvider 인터페이스는 Person 객체에 대한 포인터를 반환하는 메서드를 정의합니다. Person 구조체에는 Name 및 Age 데이터 필드가 포함되어 있습니다. Bob 구조체는 Person 구조체를 포함하고 해당 필드를 효과적으로 상속합니다.

데이터와 상호 작용하는 함수:

함수는 GetPerson() 메서드를 통해 포함된 데이터와 상호 작용할 수 있습니다.

func SayHi(pp PersonProvider) {
    fmt.Printf("Hello, %v!\r", pp.GetPerson().Name)
}

func main() {
    b := &Bob{
        5,
        Person{"Bob", 23},
    }
    SayHi(b)
    fmt.Printf("You're %v years old now!", b.Age)
}

토론:

이 기술은 데이터가 아닌 데이터를 정의하는 인터페이스를 허용합니다. 행동. 구조체가 구체적인 필드를 노출하지 않고 인터페이스를 구현할 수 있도록 하여 유연성을 높입니다. 그러나 포인터를 노출하면 여전히 데이터에 대한 직접 액세스가 허용되므로 추가적인 유연성이 제한적으로 제공된다는 점에 유의하는 것이 중요합니다.

또한 Go 규칙에서는 데이터 액세스를 위해 항상 추상화를 사용해야 하는 것은 아닙니다. 대부분의 경우 포함 또는 공개 필드를 통해 데이터 속성을 노출하는 것이 허용됩니다. 이 기술을 고려할 때 특성을 직접 노출하는 것보다 상당한 이점을 제공하는지 여부를 사례별로 평가하는 것이 좋습니다. getter 및 setter를 통해 데이터를 노출하는 것이 향후 유연성이나 API 호환성에 중요하지 않은 경우 공개 속성이 더 간단한 솔루션이 될 수 있습니다.

전반적으로 제시된 기술은 영리한 트릭이지만 그 필요성을 저울질해 보는 것이 좋습니다. 일부 상황에서는 더 적절할 수 있는 대체 접근 방식을 신중하게 고려하세요.

위 내용은 Go 인터페이스에서 데이터를 정의하기 위해 임베디드 구조체를 사용해야 할까요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!