[🐣질문] C# 인터페이스 쓰는 이유가 현실적으로 뭐임?

[익명(115.92)]

1. 코드 중복

2. 이후에 해당 클래스에서 인터페이스만 뽑아서 호출하는거

이거 말고 다른 이유 있음? ㅇㅇ;;

[211214(tomatoss)]

사실 모루겠음; 그래서 안 씀

[ㅇㅇ 1(175.127)]

각 특성별 구현을 따로나눠서 붙여두면 확장하기 편함. trait같은거임 다른 클래스의 레퍼런스를 받을때도 전체적으로 필요하지않고 interface대로 필요할수도있고. 대신 이렇게 잘 쓰려면 각 클래스별로 작은 단위로 잘 쪼개서 설계해야하기때문에 난이도는 꽤 높음. 각 특성별 공통분모와 같은 부분을 잘 쪼개야하는것도 있고

[익명(115.92)]

ㅇㅎ

[순수프로젝트(penpaper0204)]

다중상속때매 쓴듯 - dc App

[익명(115.92)]

ㅇㅎ2

[익명(115.92)]

그럼 변수는? 인터페이스는 함수만 작성 가능하던데

[순수프로젝트(penpaper0204)]

추상클래스 하나에 공통변수는 묶어놓는데 나도 개발 몇달 하다가 설계 틀어져서 몇개는 자식클래스에서 변수 따로놀음 ㅋㅋㅋ - dc App

[익명(acst0)]

인터페이스에서도 프로퍼티 선언 가능해서 사실상 변수처럼 쓸 수 있음

[순수프로젝트(penpaper0204)]

[순수프로젝트(penpaper0204)]

캬 알려줘서 ㄱㅅ 다음엔 인터페이스 더 활용도 높게 써먹겠다 - dc App

[익명(fujiwara1)]

1. 팀 작업에서 실수 할 확률 줄어듦 2. 인터페이스로 객체를 받아오면 인터페이스에서 선언된 함수 바로 실행 가능 그냥 추상함수만 있는 부모라고 생각하면 편함 근데 다중 상속이 가능한

[익명(115.92)]

ㅇㅎ3

[익명(fujiwara1)]

그리고 필드가 없는건 나도 그냥 야매로 배워서 잘 설명은 안되는데 인터페이스가 그 자체로썬 객체화(메모리 먹는?)를 할 수 없다는 특성 때문에 다중 상속이 가능하고 그래서 필드가 없는거 정도라고 대충 알고 있음

[익명(180.71)]

궁금한게 2번 설명에 추상클래스나 그냥클래스로 상속받아도 선언된함수 바로실행가능한거아니야?

[익명(fujiwara1)]

2번에 + 다중상속을 붙여야 함

[개발용더미(sy1mn1t4y83k)]

객체에 어떤 역할을 부여하고 다른 요소들과 관계 없이 사용하고 싶을때 사용하면 편함.. 대표적으로 IEnumerable 같은게 있는데 내 클래스에서 해당 인터페이스를 구현만 해두면 IEnumerable을 요구하는 각종 요소에서 사용할 수 있게 되어서 편하지. foreach 같은거 말야

[개발용더미(sy1mn1t4y83k)]

요구 명세서 라고 보면 편함. 이 함수에는 이런 함수들을 구현하고 있는 객체면 뭐가되었든 돌릴 수 있음. 이런식인거지

[익명(115.92)]

ㅇㅎ4

[211214(tomatoss)]

흠 역시 모르겠군

[익명(acst0)]

결국 팀 색깔마다 다르고 개인의 이해에 따라 달라서 정답이란 없지만 나는 일종의 모듈화 작업이라 생각함. 기본적으로 똑같은 형태의 모듈이지만 구현은 제각각일 때 다중 상속 제한도 없고 그래서 묶기가 쉬워짐

[211214(tomatoss)]

묶으면 안 되는 거 아님??

[익명(acst0)]

구현이 제각각이라는게 공통점이 없다는 건 아님... 겉에서 봤을 때 '비슷한 역할'이지만 내부 구현이 완전히 다르거나 할 때 설계에 따라 그 '역할'이라는 데 집중해야할 때가 있지

[211214(tomatoss)]

주입식으로 교육 받은 IDamageable만 활용하고 있는데.. 벽이 몬스터마냥 모든 Entity 속성을 갖고 있을 필요는 없으니까 인터페이스로 피 닳게 하는 정도? 이거 말고 어디에 쓸 수 있을 지 ㅁ?ㄹ겠음

[익명(acst0)]

애초에 객체지향의 '캡슐화' 라는 게 겉에서 봤을 때 구현 알빠노?를 지향하는거니까 그런 측면에선 오히려 구현이 제각각이든 말든 묶는거지

[익명(acst0)]

프로젝트 명세가 어떤지는 경우의 수가 무한이라 그냥 굳이 이거 인터페이스로 짜봐야겠다~ 할 필요는 없음. 걍 이거 인터페이스 각인데? 가 코딩 짬이 쌓이면 보이기 시작하는거지

[211214(tomatoss)]

[익명(acst0)]

당장 IEnumerable 생각해보셈. 리스트, 딕셔너리, 해쉬셋, 스택, 힙 등등 구현 다 제각각인데 컬렉션이라는 공통적인 역할을 수행하니까 똑같은 인터페이스로 묶은거임

[211214(tomatoss)]

ㅇㅎ..

[ㅇㅇ 2(121.170)]

한 함수에 인수 하나를 받는데 이 인수에 다양한 타입을 넣으려면 인터페이스/상속을 사용해야 함. 하나의 컬렉션에서 최댓값을 찾는 max 함수를 만들 때 인터페이스가 없다면 List, Set, Array 타입을 받는 함수를 따로따로 만들어야 하지만 IEnumerable을 받도록 만들면 함수 하나로 인터페이스를 구현하는 애들은 전부 활용할 수 있음. 이때 한 타입이 여러 타입을 띄고 있을 수 있다는 의미에서 이걸 다형성이라고 부름

[ㅇㅇ 2(121.170)]

물론 이제 현실의 프로그래밍으로 오면 단순히 이런 이유만으로 쓰는 건 아님. 해당 인터페이스를 구현한다는 것 만으로 해당 타입이 어떻게 활용될지 힌트를 줘서 추성화를 하는 효과도 있고 큰 형태를 잡아나갈 때 인터페이스를 만들어가면 설계하기 편해서 지금 당장 안 써도 미리 구현해두곤 함. 다만 과하면 복잡도가 늘어나고 불필요한 추상화는 독이 되는게 부지기수임.

[211214(tomatoss)]

[ㅇㅇ 3(220.74)]

나도 최근에 안건데 보통 다 Interact 를 예를들어 설명하는게 가장 명확함 플레이어가 다른 객체랑 상호작용을 구현한다고할때 각자 부모 상위 클래스가 다른경우 플레이어한테 모든 부모 클래스를 일일히 다 스위치문같은걸로 구분하지않고 인터렉트 함수하나만 호출할수있게됨, 즉 기능만 정의하고 필요에따라 붙였다 떼었다 할수있어서 필요한 객체에만 인터페이스 붙여서 기능하게만하면 코드 가독성및 재사용성이 많이 올라감 그전에는 몰라서 상속만받아서 일일히 스위치문으로 했었는데 이제 애매하면 걍 인터페이스로 빼고 관리함 더좋은 사용법 있으면 나도 배우고싶네

[불타는키보드(1bnmaker)]

[ㅇㅇ 4(121.173)]

연관성이 없는 완전히 다른 다른 객체들에게 (예를 들어 비행기, 자동차, 폭죽, 상자) 동일한 기능을 적용하고 그 구현은 다르게 만들고 싶을 때 인터페이스를 사용하면 편함.
예를 들어 IExplosion 인터페이스를 만들고 그 안에 Explode() 메서드를 넣어줌.
그 다음에 각각의 객체(비행기, 자동차, 폭죽, 상자 )에 폭파 효과를 넣고 싶다면 IExplosion 인터페이스를 상속받게 한 후 Explode() 메서드를 각각 상황에 맞게 구현하면 됨.
비행기, 자동차, 폭죽, 상자는 서로 상속관계가 아님
https://dev.epicgames.com/documentation/ko-kr/unreal-engine/interfaces-in-unreal-engine?application_version=5.5