[💬] 유니티에서 인터페이스를 쓰는 이유 - 댓글을 게시글로 정리

아래 있는 "유니티 인터페이스는 어떨 때 쓰는 건가요?"

질문에 달려있는 댓글이 좋아서 그냥 내가 다시 보기 위한 용도로 글로 정리함.

222.98 :

쓸때 인터페이스 형식으로 받아서 쓸수있음

Animal 상속받은 Dog와 Cat이 있는데 쓸때

Animal animal = new Dog(); 한담에

animal.Sound() 하면 Dog Sound 나오고

Animal animal = new Cat();

animal.Sound(); 하면 Cat Sound나옴

longZam :

전혀 다른 상속 계층으로부터 기능 구현을 보장받음.

위 예시에서 Animal한테 그냥 Sound를 virtual로 만들어놓고

하위 클래스에서 override 시키면 되지 않냐고 할 수 있는데,

소리를 내지 못하는 Animal은? 얘들은 override에서 구현을 비워놔야 하는건가?

또는 전혀 상관없는 Mechanic을 상속 받는 Robot은?

Animal과 Mechanic이 뭔 타입인지 상관 없이 소리만 내고 싶다면?

Soundable 클래스를 상속받아야 하는건가?

아니면 if문으로 일일이 타입 체크?

222.110 :

- 너가 원하는 관점만 노출시키기 위해서 사용하는게 인터페이스임

예를 들어서 여러 개의 총을 작동시키는 스크립트를 만든다고 치셈

내가 마우스 왼쪽을 누르면 총이 나가고, 화면 하단에는 남은 총알 수가 노출됨. 그리고 R을 누르면 리로딩이 된다고 치자.

설명한 3개의 스크립트는 각각 별개의 GO로 구현을 해서 사용하게 될 것 아님?

이럴 때 목적에 맞는 의존관계에 대해서만 메소드를 노출시키기 위해서 인터페이스를 쓰는거임

어떤 형식으로 구현된 클래스라도 `Shootable` 인터페이스가 구현되어 있으면 `Shootable` 안에 정의된 메소드는 확실히 호출 할 수 있으니까

- 그럼 왜 구현형식과 관계없이 특정 관점만 노출시키는 인터페이스가 필요하냐면.. 그것은 크게 3가지의 이유가 있음.

1) 하나는 의존 관계간 테스트 격리가 가능해짐 (더미 인터페이스를 넣으면 되기 때문에 환경을 고려하지 않는 간단한 유닛테스트를 만들기 쉬워짐)

2) 또 다른 하나는 혼자 만드는게 아니라 여럿이서 만드는 경우, 굳이 문서나 주석으로 불필요한 설명을 하지 않아도 클래스의 구조를 이해시키기가 쉬움

3) 세번째로 `실존하지 않는 코드` 에 대한 Stubbing 을 보증함.

예를 들어서 프로젝트가 커져서 모듈화같은 방법을 통해 빌드 캐시를 확보하고

유저가 게임을 단계적으로 설치 할 수 있게 하거나

서버쪽의 소스코드를 호출하는 모양의 RPC 구현을 하거나

자동으로 제네레이션되는 코드에 대해서 실제 사람이 구현하는 코드와 접합하는 경우

이런 경우들에 대해서 간극을 메꾸는데 사용됨

*간극을 메꾼다는 것은, 특정 시점 T에 프로젝트에 특정 코드가 준비되어 있지 않더라도

메모리에서 특정 인터페이스에 대한 메모리구조를 이해하고 있기 때문에 게으른 배포? 가 되더라도

유기적으로 런타임에서 호출 할 수 있다는 것임.

이러한 인터페이스를 잘 사용하기 위해서는

인터페이스의 역할을 SRP (단일 책임 원칙) 에 근거해서 구현하는게 중요함.

분명 인터페이스의 메소드는 shot 이라고 구현해놓고

shot 안에 shot 에 포함된다고 볼 수 없는 코드가 추가되어 있다던가..

그런 작업을 하면 오히려 인터페이스가 남용된 코드에선 뭐가 문제인지 확인하기 더 귀찮아짐

125.248 :

차라리 새로운 글을 써라 게이야

유익한 건 보기 편하게 댓보다 글로 쓰는게 정석이여

댓글 1