Microsoft MVP성태의 닷넷 이야기
VC++: 149. Golang - 인터페이스 포인터가 의미 있을까요? [링크 복사], [링크+제목 복사],
조회: 15655
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

Golang - 인터페이스 포인터가 의미 있을까요?

그렇습니다. 정말 몰라서 질문하는 것입니다. ^^

설명을 위해, Go 언어에서 간단하게 인터페이스를 구현해 볼까요? ^^

package main

import "fmt"

type Person interface {
    GetAge() int
}

type Student struct {
    Age int
}

func (student Student) GetAge() int {
    return student.Age
}

func main() {
    student := Student{ Age: 5 }

    person := student
    fmt.Println(person.GetAge())
}

C/C++에 익숙하신 분들은, 위의 경우 GetAge 함수가 값 복사가 된 Student 인스턴스가 넘어왔다는 것을 알 것입니다. 그래서, GetAge 함수에서 값을 변경해도 호출 측에서 넘겨준 인스턴스의 값을 변경할 수는 없습니다.

func (student Student) GetAge() int {
    student.Age = 10
    return student.Age
}

func main() {
    student := Student{ Age: 5 }

    person := student
    fmt.Println(person.GetAge()) // 출력 결과: 10

    fmt.Println(student.Age) // 출력 결과: 5
}

만약, 호출 측의 인스턴스에 영향을 주고 싶다면 GetAge 함수 선언을 다음과 같이 포인터 형식으로 바꿔야 합니다.

func (student *Student) GetAge() int {
    student.Age = 10
    return student.Age
}

func main() {
    student := Student{ Age: 5 }

    person := &student
    fmt.Println(person.GetAge()) // 출력 결과: 10

    fmt.Println(student.Age) // 출력 결과: 10
}

그런데 위에서 좀 재미있는 부분이 있지 않나요? 즉, 인터페이스 측에 선언한 GetAge 함수의 signature와는 별도로 그 규약을 따르는 타입 측에서는 GetAge라는 함수를 2가지 유형으로 정의할 수 있다는 점입니다.

// receiver를 값 형식으로 받는 함수로 정의해도 되고.
func (student Student) GetAge() int {
	return student.Age
}

// 포인터 형식을 받는 함수로 정의해도 되고.
func (student *Student) GetAge() int {
	return student.Age
}

게다가 둘 중 하나만 가능합니다. 그렇지 않으면 다음과 같은 식으로 컴파일 오류가 발생합니다.

# command-line-arguments
.\main.go:19:6: method redeclared: Student.GetAge
    method(Student) func() int
    method(*Student) func() int

어쩔 수 없습니다. 만약 저런 경우가 필요하다면 각각의 함수 이름을 달리해 만들어야 합니다.




그런데, 이런 규칙이 인터페이스를 인자로 받아들이는 경우가 되면 약간 혼란이 옵니다. 가령, 다음과 같은 예제 코드에서,

package main

import "fmt"

type Person interface {
    GetAge() int
}

type Student struct {
    Age int
}

type MyFunc func(person Person)

func (student Student) GetAge() int {
    return student.Age
}

func main() {
    student := Student{ Age: 5 }

    func1 := func(person Person) {
        fmt.Println(person.GetAge())
    }

    func1(student)

    fmt.Println(student.Age)
}

값 복사를 막기 위해 포인터 처리를 해야 한다면 어떻게 될까요? 이때 자칫 실수의 여지가 있는데요, 소스 코드가 복잡하다 보면 아래와 같은 식의 시도도 할 수 있다는 점입니다.

type MyFunc func(person *Person)

func (student Student) GetAge() int {
    return student.Age
}

func main() {
    student := Student{ Age: 5 }

    func1 := func(person Person) {
        fmt.Println(person.GetAge())
    }

    func1(student)
    fmt.Println(student.Age)
}

무심코 ":=" 연산자를 사용했기 때문에 위의 코드는 컴파일 오류도 발생하지 않습니다. 왜냐하면 ":="로 하는 경우 기존 타입 정의가 없어도 Go 컴파일러가 추론으로 타입을 처리하기 때문에 위에서 MyFunc 타입과 독립적으로 "func1" 변수의 타입이 정의되기 때문입니다. 따라서, 원래 의도한 대로라면 다음과 같이 명시적으로 MyFunc와 func1을 연결해야 합니다.

type MyFunc func(person *Person)

func main() {
    student := Student{ Age: 5 }

    /* 컴파일 오류
.\main.go:23:8: cannot use func literal (type func(Person)) as type MyFunc in assignment
    */      
    var func1 MyFunc
    func1 = func(person Person) {
        fmt.Println(person.GetAge())
    }

    /* 컴파일 오류
.\main.go:27:7: cannot use student (type Student) as type *Person in argument to func1:
	*Person is pointer to interface, not interface
    */    
    func1(student)
    fmt.Println(student.Age)
}

이제는 컴파일 오류가 발생하는 것이 당연하지만, 그렇다고 양측의 타입을 일치시켜도 여전히 오류가 발생합니다.

func main() {
    student := Student{ Age: 5 }

    /* 이제는 타입 추론으로 변경 */
    func1 := func(person *Person) {
        /* 컴파일 오류
.\main.go:24:21: person.GetAge undefined (type *Person is pointer to interface, not interface)
        */
        fmt.Println(person.GetAge())
    }

    /* 컴파일 오류
.\main.go:27:7: cannot use student (type Student) as type *Person in argument to func1:
	*Person is pointer to interface, not interface
    */
    func1(student)

    /* 컴파일 오류
.\main.go:29:8: cannot use &student (type *Student) as type *Person in argument to func1:
	*Person is pointer to interface, not interface
    */
    func1(&student)

    fmt.Println(student.Age)
}

위와 같은 경우에 대한 근본적인 원인은, Go 언어에서 인터페이스는 포인터 타입이 없다는 것입니다. 따라서, 위와 같은 경우 인터페이스가 아닌 구현 타입 측에서만 포인터 처리를 해 주면 됩니다.

func (student *Student) GetAge() int {
    student.Age = 10
    return student.Age
}

func main() {
    student := Student{ Age: 5 }

    func1 := func(person Person) {
        fmt.Println(person.GetAge()) // 출력 결과 10
    }

    func1(&student)
    fmt.Println(student.Age) // 출력 결과 10
}

자칫 이전의 C/C++ 느낌으로 인터페이스를 포인터 처리하게 되면 "[Type] is pointer to interface, not interface"라는 오류에서 헤매게 될 것입니다. ^^;




이에 대한 자세한 설명을 다음의 문서에서 볼 수 있습니다.

Interface values
; https://tour.golang.org/methods/11

// An interface value holds a value of a specific underlying concrete type.

정리해 보면, interface 변수는 타입 정보를 보관한다는 것인데, 인터페이스 포인터 형식이라면 "그 타입 정보에 대한 포인터"가 되는데 그런 의미에서 딱히 유용한 형식으로 보이진 않습니다. 사실 interface 변수의 기본값은 nil이라는 점에서 그것 자체가 포인터와 닮아 있긴 합니다. 그러므로, 애당초 인터페이스 변수에 값을 담을 수도 있고, 참조를 담을 수도 있으므로 인터페이스 자체의 포인터를 선언할 필요가 없는 것입니다.

type Space interface {
    GetPosition() (x, y int)
}

type Point struct {
    X int
    Y int
}

func main() {

    pt := Point{5,10}
    var space1, space2 Space
    space1 = pt // 값도 담을 수 있고,
    space2 = &pt // 참조도 담을 수 있고
    space1.GetPosition()
    space2.GetPosition()
}

그런데, 여기서 또 재미있는 것은 인터페이스의 정의와는 무관하게 그것에 맞춰 구현하는 타입의 receiver가 어떤 메서드를 포함했느냐에 따라 위의 코드가 컴파일 오류가 발생할 수도 있다는 점입니다.

가령, 위의 예제에서 SetPosition만을 다음과 같이 추가하면,

type Space interface {
    GetPosition() (x, y int)
    SetPosition(x, y int)
}

...[생략]...

func (pt *Point) SetPosition(x, y int) {
    pt.X, pt.Y = x, y
}

컴파일 시 이제는 다음과 같은 오류가 발생합니다.

func main() {

    pt := Point{5,10}
    var space1, space2 Space

    /* 컴파일 오류
.\main.go:46:9: cannot use pt (type Point) as type Space in assignment:
	Point does not implement Space (SetPosition method has pointer receiver)
    */
    space1 = pt

    space2 = &pt
    space1.GetPosition()
    space2.GetPosition()
}

즉, SetPosition 메서드에 포인터 형의 receiver가 정의되었으므로 값으로는 더 이상 받을 수 없다는 것입니다. 따라서 이런 경우에는 무조건 "space2 = &pt"와 같이 포인터 값을 보관하는 것만 가능합니다.




인터페이스와 관련해 또 하나 실수할 수 있는 여지를 하나 볼까요? ^^

가령, 처음에는 대상 타입의 포인터를 가리켜 다음과 같이 잘 사용하던 코드가 있다고 가정했을 때,

type Student struct {
    Age int
}

type Company struct {
    Owner *Student
}

func main() {

    student := Student{ Age: 5 }
    company := Company{&student}
    fmt.Println(company.Owner.GetAge())

    fmt.Println(student.Age)
}

나중에 리팩터링을 하면서 Company의 Student를 인터페이스로 변경하는 일이 발생해 무심코 타입명만 변경해 버리면 다시 컴파일 오류에 시달리게 됩니다.

type Person interface {
    GetAge() int
}

type Student struct {
    Age int
}

// ...[생략]...

type Company struct {
    Owner *Person
}

func main() {

    student := Student{ Age: 5 }

    /* 컴파일 오류
.\main.go:60:21: cannot use &student (type *Student) as type *Person in field value:
	*Person is pointer to interface, not interface
    */
    company := Company{&student}

    /* 컴파일 오류
.\main.go:61:27: company.Owner.GetAge undefined (type *Person is pointer to interface, not interface)
    */    
    fmt.Println(company.Owner.GetAge())

    fmt.Println(student.Age)
}

명심하세요, 절대 인터페이스는 포인터 타입이 와서는 안 됩니다. ^^

type Company struct {
    Owner Person
}

// 이하 정상 컴파일

저럴 거면, 아예 인터페이스 타입의 필드를 정의하는 단계에서 불가능하게 처리를 했어야 하지 않을까요? 혹시, 이 글을 읽고 있는 분들 중에 인터페이스를 포인터 타입으로 선언해 사용한 좋은 사례가 있는지, 있다면 덧글 부탁드립니다. ^^




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 9/6/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 91  92  93  94  [95]  96  97  98  99  100  101  102  103  104  105  ...
NoWriterDateCnt.TitleFile(s)
11559정성태6/25/201828574개발 환경 구성: 384. 영문 설정의 Windows 10 명령행 창(cmd.exe)의 한글 지원 [6]
11558정성태6/24/201822157.NET Framework: 775. C# 7.3 - unmanaged(blittable) 제네릭 제약파일 다운로드1
11557정성태6/22/201821652.NET Framework: 774. C# - blittable 타입이란?파일 다운로드1
11556정성태6/19/201828543.NET Framework: 773. C# 7.3 - 구조체의 고정 크기를 갖는 fixed 배열 필드에 대한 직접 접근 가능 [1]파일 다운로드1
11555정성태6/18/201820237.NET Framework: 772. C# 7.3 - 사용자 정의 타입에 fixed 적용 가능(Custom fixed)파일 다운로드1
11554정성태6/17/201822236.NET Framework: 771. C# 7.3 - 자동 구현 속성에 특성 적용 가능(Attribute on backing field)
11553정성태6/15/201821865.NET Framework: 770. C# 7.3 - 개선된 메서드 선택 규칙 3가지(Improved overload candidates)파일 다운로드1
11552정성태6/15/201823807.NET Framework: 769. C# 7.3에서 개선된 문법 4개(Support == and != for tuples, Ref Reassignment, Constraints, Stackalloc initializers)파일 다운로드1
11551정성태6/14/201820422개발 환경 구성: 383. BenchmarkDotNet 사용 시 주의 사항
11550정성태6/13/201820327.NET Framework: 768. BenchmarkDotNet으로 Span<T> 성능 측정 [2]
11549정성태6/13/201821928개발 환경 구성: 382. BenchmarkDotNet에서 생성한 BuildPlots.R 파일을 실행하는 방법
11548정성태6/13/201819187오류 유형: 470. .NET Core + BenchmarkDotNet 실행 시 프레임워크를 찾지 못하는 문제
11547정성태6/13/201824271.NET Framework: 767. BenchmarkDotNet 라이브러리 소개파일 다운로드1
11546정성태6/12/201824431.NET Framework: 766. C# 7.2의 특징 - GC 및 메모리 복사 방지를 위한 struct 타입 개선 [9]파일 다운로드1
11545정성태6/11/201822679오류 유형: 469. .NET Core 프로젝트를 Visual Studio에서 실행 시 System.BadImageFormatException 발생하는 경우 [1]
11544정성태6/10/201822242.NET Framework: 765. C# 7.2 - 숫자 리터럴의 선행 밑줄과 뒤에 오지 않는 명명된 인수
11543정성태6/9/201821834.NET Framework: 764. C# 7.2 - private protected 접근자 추가파일 다운로드1
11542정성태6/9/201860243개발 환경 구성: 381. Azure Web App 확장 예제 - Remove Custom Headers
11541정성태6/9/201819399개발 환경 구성: 380. Azure Web App 확장 배포 방법 [1]
11540정성태6/9/201820213개발 환경 구성: 379. Azure Web App 확장 예제 제작 [2]
11539정성태6/8/201819994.NET Framework: 763. .NET Core 2.1 - Tiered Compilation 도입파일 다운로드1
11538정성태6/8/201819263.NET Framework: 762. .NET Core 2.1 - 확장 도구(Tools) 관리 [1]
11537정성태6/8/201823770.NET Framework: 761. C# - SmtpClient로 SMTP + SSL/TLS 서버를 이용하는 방법 [5]
11536정성태6/7/201821420.NET Framework: 760. Microsoft Build 2018 - The future of C# 동영상 내용 정리 [1]파일 다운로드1
11535정성태6/7/201823265.NET Framework: 759. C# - System.Span<T> 성능 [1]
11534정성태6/6/201829036.NET Framework: 758. C# 7.2 - Span<T> [6]
... 91  92  93  94  [95]  96  97  98  99  100  101  102  103  104  105  ...