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

비밀번호

댓글 작성자
 




... 76  77  78  79  80  81  82  83  [84]  85  86  87  88  89  90  ...
NoWriterDateCnt.TitleFile(s)
11836정성태3/5/201923184오류 유형: 525. Visual Studio 2019 Preview 4/RC - C# 8.0 Missing compiler required member 'System.Range..ctor' [1]
11835정성태3/5/201921708.NET Framework: 810. C# 8.0의 Index/Range 연산자를 .NET Framework에서 사용하는 방법 및 비동기 스트림의 컴파일 방법 [3]파일 다운로드1
11834정성태3/4/201920550개발 환경 구성: 432. Visual Studio 없이 최신 C# (8.0) 컴파일러를 사용하는 방법
11833정성태3/4/201921051개발 환경 구성: 431. Visual Studio 2019 - CMake를 이용한 공유/실행(so/out) 리눅스 프로젝트 설정파일 다운로드1
11832정성태3/4/201916990오류 유형: 524. Visual Studio CMake - rsync: connection unexpectedly closed
11831정성태3/4/201916807오류 유형: 523. Visual Studio 2019 - 새 창으로 뜬 윈도우를 닫을 때 비정상 종료
11830정성태2/26/201916497오류 유형: 522. 이벤트 로그 - Error opening event log file State. Log will not be processed. Return code from OpenEventLog is 87.
11829정성태2/26/201918253개발 환경 구성: 430. 마이크로소프트의 CoreCLR 프로파일러 예제 빌드 방법 - 리눅스 환경 [1]
11828정성태2/26/201926126개발 환경 구성: 429. Component Services 관리자의 RuntimeBroker 설정이 2개 있는 경우 [8]
11827정성태2/26/201919049오류 유형: 521. Visual Studio - Could not start the 'rsync' command on the remote host, please install it using your system package manager.
11826정성태2/26/201919242오류 유형: 520. 우분투에 .NET Core SDK 설치 시 패키지 의존성 오류
11825정성태2/25/201924449개발 환경 구성: 428. Visual Studio 2019 - CMake를 이용한 리눅스 빌드 환경 설정 [1]
11824정성태2/25/201918891오류 유형: 519. The SNMP Service encountered an error while accessing the registry key SYSTEM\CurrentControlSet\Services\SNMP\Parameters\TrapConfiguration. [1]
11823정성태2/21/201920616오류 유형: 518. IIS 관리 콘솔이 뜨지 않는 문제
11822정성태2/20/201918908오류 유형: 517. docker에 설치한 MongoDB 서버로 연결이 안 되는 경우
11821정성태2/20/201919673오류 유형: 516. Visual Studio 2019 - This extension uses deprecated APIs and is at risk of not functioning in a future VS update. [1]
11820정성태2/20/201922741오류 유형: 515. 윈도우 10 1809 업데이트 후 "User Profiles Service" 1534 경고 발생
11819정성태2/20/201922025Windows: 158. 컴퓨터와 사용자의 SID(security identifier) 확인 방법
11818정성태2/20/201920064VS.NET IDE: 131. Visual Studio 2019 Preview의 닷넷 프로젝트 빌드가 20초 이상 걸리는 경우 [2]
11817정성태2/17/201916445오류 유형: 514. WinDbg Preview 실행 오류 - Error : DbgX.dll : WindowsDebugger.WindowsDebuggerException: Could not load dbgeng.dll
11816정성태2/17/201919850Windows: 157. 윈도우 스토어 앱(Microsoft Store App)을 명령행에서 직접 실행하는 방법
11815정성태2/14/201918096오류 유형: 513. Visual Studio 2019 - VSIX 설치 시 "The extension cannot be installed to this product due to prerequisites that cannot be resolved." 오류 발생
11814정성태2/12/201916963오류 유형: 512. VM(가상 머신)의 NT 서비스들이 자동 시작되지 않는 문제
11813정성태2/12/201918312.NET Framework: 809. C# - ("Save File Dialog" 등의) 대화 창에 확장 속성을 보이는 방법
11812정성태2/11/201915609오류 유형: 511. Windows Server 2003 VM 부팅 후 로그인 시점에 0xC0000005 BSOD 발생
11811정성태2/11/201920790오류 유형: 510. 서버 운영체제에 NVIDIA GeForce Experience 실행 시 wlanapi.dll 누락 문제
... 76  77  78  79  80  81  82  83  [84]  85  86  87  88  89  90  ...