Microsoft MVP성태의 닷넷 이야기
VC++: 149. Golang - 인터페이스 포인터가 의미 있을까요? [링크 복사], [링크+제목 복사],
조회: 15647
글쓴 사람
정성태 (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

비밀번호

댓글 작성자
 




... [106]  107  108  109  110  111  112  113  114  115  116  117  118  119  120  ...
NoWriterDateCnt.TitleFile(s)
11274정성태8/22/201719338.NET Framework: 674. Thread 타입의 Suspend/Resume/Join 사용 관련 예외 처리
11273정성태8/22/201721625오류 유형: 415. 윈도우 업데이트 에러 Error 0x80070643
11272정성태8/21/201724775VS.NET IDE: 120. 비주얼 스튜디오 2017 버전 15.3.1 - C# 7.1 공개 [2]
11271정성태8/19/201719199VS.NET IDE: 119. Visual Studio 2017에서 .NET Core 2.0 프로젝트 환경 구성하는 방법
11270정성태8/17/201730666.NET Framework: 673. C#에서 enum을 boxing 없이 int로 변환하기 [2]
11269정성태8/17/201721454디버깅 기술: 93. windbg - 풀 덤프에서 .NET 스레드의 상태를 알아내는 방법
11268정성태8/14/201721020디버깅 기술: 92. windbg - C# Monitor Lock을 획득하고 있는 스레드 찾는 방법
11267정성태8/10/201725092.NET Framework: 672. 모노 개발 환경
11266정성태8/10/201724901.NET Framework: 671. C# 6.0 이상의 소스 코드를 Visual Studio 설치 없이 명령행에서 컴파일하는 방법
11265정성태8/10/201753133기타: 66. 도서: 시작하세요! C# 7.1 프로그래밍: 기본 문법부터 실전 예제까지 [11]
11264정성태8/9/201724030오류 유형: 414. UWP app을 signtool.exe로 서명 시 0x8007000b 오류 발생
11263정성태8/9/201719518오류 유형: 413. The C# project "..." is targeting ".NETFramework, Version=v4.0", which is not installed on this machine. [3]
11262정성태8/5/201718220오류 유형: 412. windbg - SOS does not support the current target architecture. [3]
11261정성태8/4/201720812디버깅 기술: 91. windbg - 풀 덤프 파일로부터 강력한 이름의 어셈블리 추출 후 사용하는 방법
11260정성태8/3/201718896.NET Framework: 670. C# - 실행 파일로부터 공개키를 추출하는 방법
11259정성태8/2/201718130.NET Framework: 669. 지연 서명된 어셈블리를 sn.exe -Vr 등록 없이 사용하는 방법
11258정성태8/1/201718920.NET Framework: 668. 지연 서명된 DLL과 서명된 DLL의 차이점파일 다운로드1
11257정성태7/31/201719139.NET Framework: 667. bypassTrustedAppStrongNames 옵션 설명파일 다운로드1
11256정성태7/25/201720611디버깅 기술: 90. windbg의 lm 명령으로 보이지 않는 .NET 4.0 ClassLibrary를 명시적으로 로드하는 방법 [1]
11255정성태7/18/201723179디버깅 기술: 89. Win32 Debug CRT Heap Internals의 0xBAADF00D 표시 재현 [1]파일 다운로드3
11254정성태7/17/201719511개발 환경 구성: 322. "Visual Studio Emulator for Android" 에뮬레이터를 "Android Studio"와 함께 쓰는 방법
11253정성태7/17/201719815Math: 21. "Coding the Matrix" 문제 2.5.1 풀이 [1]파일 다운로드1
11252정성태7/13/201718423오류 유형: 411. RTVS 또는 PTVS 실행 시 Could not load type 'Microsoft.VisualStudio.InteractiveWindow.Shell.IVsInteractiveWindowFactory2'
11251정성태7/13/201717086디버깅 기술: 88. windbg 분석 - webengine4.dll의 MgdExplicitFlush에서 발생한 System.AccessViolationException의 crash 문제 (2)
11250정성태7/13/201720669디버깅 기술: 87. windbg 분석 - webengine4.dll의 MgdExplicitFlush에서 발생한 System.AccessViolationException의 crash 문제 [1]
11249정성태7/12/201718480오류 유형: 410. LoadLibrary("[...].dll") failed - The specified procedure could not be found.
... [106]  107  108  109  110  111  112  113  114  115  116  117  118  119  120  ...