Microsoft MVP성태의 닷넷 이야기
VC++: 149. Golang - 인터페이스 포인터가 의미 있을까요? [링크 복사], [링크+제목 복사],
조회: 15742
글쓴 사람
정성태 (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)
10949정성태4/28/201619936.NET Framework: 575. SharedDomain과 JIT 컴파일파일 다운로드1
10948정성태4/28/201623900.NET Framework: 574. .NET - 눈으로 확인하는 SharedDomain의 동작 방식 [3]파일 다운로드1
10947정성태4/27/201621780.NET Framework: 573. .NET CLR4 보안 모델 - 4. CLR4 보안 모델에서의 조건부 APTCA 역할파일 다운로드1
10946정성태4/26/201624565VS.NET IDE: 106. Visual Studio 2015 확장 - INI 파일을 위한 사용자 정의 포맷 기능 (Syntax Highlighting)파일 다운로드1
10945정성태4/26/201618340오류 유형: 327. VSIX 프로젝트 빌드 시 The "VsTemplatePaths" task could not be loaded from the assembly 오류 발생
10944정성태4/22/201619559디버깅 기술: 80. windbg - 풀 덤프 파일로부터 텍스트 파일의 내용을 찾는 방법
10943정성태4/22/201624416디버깅 기술: 79. windbg - 풀 덤프 파일로부터 .NET DLL을 추출/저장하는 방법 [1]
10942정성태4/19/201619724디버깅 기술: 78. windbg 사례 - .NET 예외가 발생한 시점의 오류 분석 [1]
10941정성태4/19/201619635오류 유형: 326. Error MSB8020 - The build tools for v120_xp (Platform Toolset = 'v120_xp') cannot be found.
10940정성태4/18/201622931Windows: 116. 프로세스 풀 덤프 시간을 줄여 주는 Process Reflection [3]
10939정성태4/18/201623936.NET Framework: 572. .NET APM 비동기 호출의 Begin...과 End... 조합 [3]파일 다운로드1
10938정성태4/13/201623501오류 유형: 325. 파일 삭제 시 오류 - Error 0x80070091: The directory is not empty.
10937정성태4/13/201631693Windows: 115. UEFI 모드로 윈도우 10 설치 가능한 USB 디스크 만드는 방법
10936정성태4/8/201642443Windows: 114. 삼성 센스 크로노스 7 노트북의 운영체제를 USB 디스크로 새로 설치하는 방법 [3]
10935정성태4/7/201626712웹: 32. Edge에서 Google Docs 문서 편집 시 한영 전환키가 동작 안하는 문제
10934정성태4/5/201625404디버깅 기술: 77. windbg의 콜스택 함수 인자를 쉽게 확인하는 방법 [1]
10933정성태4/5/201631038.NET Framework: 571. C# - 스레드 선호도(Thread Affinity) 지정하는 방법 [8]파일 다운로드1
10932정성태4/4/201623314VC++: 96. C/C++ 식 평가 - printf("%d %d %d\n", a, a++, a);
10931정성태3/31/201623606개발 환경 구성: 283. Hyper-V 내에 구성한 Active Directory 환경의 시간 구성 방법 [3]
10930정성태3/30/201621572.NET Framework: 570. .NET 4.5부터 추가된 CLR Profiler의 실행 시 Rejit 기능
10929정성태3/29/201631674.NET Framework: 569. ServicePointManager.DefaultConnectionLimit의 역할파일 다운로드1
10928정성태3/28/201637376.NET Framework: 568. ODP.NET의 완전한 닷넷 버전 Oracle ODP.NET, Managed Driver [2]파일 다운로드1
10927정성태3/25/201626576.NET Framework: 567. System.Net.ServicePointManager의 DefaultConnectionLimit 속성 설명
10926정성태3/24/201626135.NET Framework: 566. openssl의 PKCS#1 PEM 개인키 파일을 .NET RSACryptoServiceProvider에서 사용하는 방법 [10]파일 다운로드1
10925정성태3/24/201620423.NET Framework: 565. C# - Rabin-Miller 소수 생성 방법을 이용하여 RSACryptoServiceProvider의 개인키를 직접 채워보자 - 두 번째 이야기파일 다운로드1
10924정성태3/22/201621116오류 유형: 324. Visual Studio에서 Azure 클라우드 서비스 생성 시 Failed to initialize the PowerShell host 에러 발생
... 106  107  108  109  110  111  112  113  114  115  116  117  118  [119]  120  ...