Unity로 게임을 개발할 때 OOP 기능을 선호합니다. 나는 일반적으로 기본 클래스 (주로 추상화 됨)를 만들고 객체 상속을 사용하여 다양한 다른 객체와 동일한 기능을 공유합니다.

그러나 최근에는 상속을 사용하지 말아야한다고 누군가에게 들었습니다. 대신 인터페이스를 사용해야합니다. 나는 왜 그런지 물었고, 그는 "물론 상속이 중요하지만 확장 된 객체가 많으면 클래스 간의 관계가 밀접하게 연관되어있다"고 말했다.

나는 뭔가를 추상 기본 클래스를 사용하고 있습니다 WeaponBase와 같은 특정 무기 클래스를 생성 Shotgun, AssaultRifle, Machinegun뭐 그런. 많은 장점이 있습니다. 제가 정말로 즐기는 한 가지 패턴은 다형성입니다. 서브 클래스가 생성 한 객체를 기본 클래스 인 것처럼 취급하여 로직을 대폭 줄이고 재사용 할 수 있습니다. 하위 클래스의 필드 또는 메소드에 액세스해야하는 경우 하위 클래스로 캐스트합니다.

나는 일반적으로 다른 클래스에서 사용 같은 필드를 정의하지 않으 같은 AudioSource/ Rigidbody/ Animator내가 같이 정의 된 멤버 필드 많은 fireRate, damage, range, spread등. 또한 경우에 따라 일부 방법을 덮어 쓸 수도 있습니다. 따라서이 경우 가상 메서드를 사용하고 있으므로 기본적으로 부모 클래스의 메서드를 사용하여 해당 메서드를 호출 할 수 있지만 자식의 논리가 다르면 수동으로 재정의했습니다.

그렇다면이 모든 것을 나쁜 습관으로 버려야합니까? 대신 인터페이스를 사용해야합니까?

엔티티 및 재고 / 항목 시스템에서 상속보다 구성을 선호 하십시오. 이 조언은 게임 로직 구조에 적용되는 경향이 있습니다. 런타임에 복잡한 것을 조립할 수있는 방법이 많은 다른 조합으로 이어질 수 있습니다. 그것은 우리가 작곡을 선호 할 때입니다.

UI 구성부터 서비스에 이르기까지 응용 프로그램 수준 논리의 구성보다 상속을 선호 합니다. 예를 들어

Widget->Button->SpinnerButton 또는

ConnectionManager->TCPConnectionManager대 ->UDPConnectionManager.

... 여기에는 잠재적 인 파생물이 아니라 명확하게 정의 된 파생 계층 구조가 있으므로 상속을 사용하는 것이 더 쉽습니다.

결론 : 가능한 곳에서는 상속을 사용하지만 필요한 곳에서는 구성을 사용하십시오. PS 엔터티 시스템에서 구성을 선호하는 또 다른 이유는 일반적으로 엔터티가 많고 상속시 모든 개체의 멤버에 액세스하는 데 성능 비용이 발생할 수 있기 때문입니다. vtables 참조하십시오 .

당신은 이미 몇 가지 좋은 답변을 얻었지만 질문의 방에있는 거대한 코끼리는 이것입니다.

상속을 사용해서는 안된다는 누군가의 말을 듣고 대신 인터페이스를 사용해야합니다

경험상 누군가 누군가가 경험할 때 무시하십시오. 이것은 "누군가에게 무언가를 말해주는 것"뿐만 아니라 인터넷에서 물건을 읽는데도 사용됩니다. 이유 를 알지 못하면 (그리고 실제로 그것을 뒷받침 할 수있는 경우), 그러한 조언은 가치가없고 종종 매우 해 롭습니다.

내 경험상 OOP에서 가장 중요하고 유용한 개념은 "낮은 커플 링"과 "높은 응집성"입니다 (클래스 / 객체는 서로에 대해 가능한 한 적게 알고 있으며 각 단위는 가능한 한 적은 수의 책임을집니다).

낮은 커플 링

즉, 코드에 포함 된 모든 "번들"은 가능한 한 주변 환경에 의존해야합니다. 이것은 클래스 (클래스 디자인)뿐만 아니라 객체 (실제 구현), 일반적으로 "파일"(예 : #include단일 .cpp파일 당 s 수, 단일 파일 import당 수 등 .java)에 적용됩니다.

두 엔티티가 결합되었다는 신호는 다른 엔티티가 어떤 방식 으로든 변경 될 때 그 중 하나가 끊어 지거나 변경되어야한다는 것입니다.

상속은 분명히 커플 링을 증가시킵니다. 기본 클래스를 변경하면 모든 하위 클래스가 변경됩니다.

인터페이스는 커플 링을 줄입니다. 명확한 방법 기반 계약을 정의하면 계약을 변경하지 않는 한 인터페이스의 양쪽 측면을 자유롭게 변경할 수 있습니다. "인터페이스"는 일반적인 개념이며 Java interface또는 C ++ 추상 클래스는 구현 세부 사항 일뿐입니다.

높은 응집력

이것은 각 클래스, 객체, 파일 등이 가능한 한 적게 관심을 갖거나 책임을 지도록하는 것을 의미합니다. 즉, 많은 일을하는 큰 수업을 피하십시오. 예를 들어, 무기에 완전히 다른 측면 (탄약, 발사 행동, 그래픽 표현, 인벤토리 표현 등)이있는 경우, 그 중 하나를 정확하게 나타내는 다른 클래스를 가질 수 있습니다. 주무기 클래스는 그런 세부 사항의 "홀더"로 변형됩니다. 무기 오브젝트는 그 세부 사항에 대한 몇 가지 포인터에 지나지 않습니다.

이 예에서는 "발사 행동"을 나타내는 클래스가 주 무기 클래스에 대해 인간적으로 가능한 한 적은 것을 알고 있는지 확인합니다. 최적의 것은 전혀 없습니다. 예를 들어, 이것은 손가락 하나만으로 세계의 모든 물체 (포탑, 화산, NPC 등)에 "발화 행동"을 줄 수 있음을 의미 합니다. 특정 시점에서 무기가 인벤토리에 표시되는 방식을 변경하려는 경우 간단히 그렇게 할 수 있습니다. 인벤토리 클래스 만 알 수 있습니다.

개체가 응집 적이 지 않다는 신호는 개체가 동시에 여러 방향으로 분기되어 점점 커지는 경우입니다.

당신이 묘사 할 때 상속은 응집력을 감소시킵니다. 무기 클래스는 하루 종일 무기의 모든 종류의 서로 관련이없는 다양한 측면을 처리하는 큰 덩어리입니다.

인터페이스는 인터페이스의 양면에서 책임을 명확하게 분리하여 간접적으로 응집력을 높입니다.

지금해야 할 일

여전히 단단하고 빠른 규칙은 없지만이 모든 것은 단지 지침 일뿐입니다. 일반적으로 사용자 TKK가 그의 답변에서 언급했듯이 상속은 학교와 책에서 많이 가르쳐집니다. OOP의 멋진 점입니다. 인터페이스는 아마도 가르치는 데 지루하고, (사소한 예제를 지나친다면) 조금 더 어려워서 의존성 주입 필드를 열어서 상속만큼 명확하지 않습니다.

하루가 끝날 무렵에도 상속 기반 체계는 명확한 OOP 디자인을 전혀 사용하지 않는 것보다 낫습니다. 따라서 자유롭게 고수하십시오. 원한다면 Low Coupling, High Cohesion에 대해 약간의 결론을 내릴 수 있으며 그러한 종류의 사고를 무기고에 추가하고 싶은지 확인할 수 있습니다. 나중에 원한다면 언제든지 다시 시도해 볼 수 있습니다. 또는 더 큰 차세대 코드 모듈에서 인터페이스 기반 접근 방식을 시도해보십시오.

상속을 피해야한다는 생각은 단순히 잘못된 것입니다.

컴포지션 오버 상속 이라는 코딩 원칙이 있습니다 . 컴포지션으로 동일한 것을 달성 할 수 있다고 말하며 코드 중 일부를 재사용 할 수 있기 때문에 바람직합니다. 상속보다 구성을 선호해야하는 이유를 참조하십시오 .

나는 당신의 무기 클래스를 좋아한다고 말해야하며 같은 방식으로 할 것입니다. 하지만 지금까지 게임을 만들지 않았습니다 ...

제임스 트로터 (James Trotter)가 지적한 바와 같이, 컴포지션은 특히 무기의 작동 방식을 변경할 수있는 런타임 유연성에서 몇 가지 장점을 가질 수 있습니다. 이것은 상속으로 가능하지만 더 어렵습니다.

문제는 상속으로 인해 커플 링이 발생한다는 것입니다. 객체는 서로에 대해 더 알아야합니다. 그렇기 때문에 규칙은 "항상 상속보다 구성을 선호합니다"입니다. 이것은 상속을 사용하지 않는다는 것을 의미하는 것이 아니며, 그것이 완전히 적절한 곳에서 사용하는 것을 의미합니다. 그러나 만약 당신이 거기에 앉아 있다면 "이 두 가지 방법으로 할 수 있고 둘 다 이해할 수 있습니다."

상속은 또한 일종의 제한이 될 수 있습니다. AssultRifle이 될 수있는 "WeaponBase"가 있습니다. 이중 배럴 산탄 총이 있고 배럴을 독립적으로 발사하기를 원할 때 발생하는 상황-조금 어렵지만 실행 가능하지만 단일 배럴 및 이중 배럴 클래스 만 있지만 단일 배럴 2 개만 장착 할 수는 없습니다. 같은 총에 당신은 할 수 있습니까? 3 배럴을 갖도록 하나를 개조 할 수 있습니까? 아니면 새로운 클래스가 필요합니까?

수류탄 발사기가 장착 된 AssultRifle은 어떻습니까? 야간 사냥을 위해 수류탄을 손전등으로 교체 할 수 있습니까?

마지막으로, 구성 파일을 편집하여 사용자가 어떻게 선행 건을 만들 수 있습니까? 데이터로 구성하고 구성하는 것이 더 나을 수있는 관계를 하드 코딩했기 때문에 어렵습니다.

다중 상속은 이러한 사소한 예제 중 일부를 다소 수정할 수 있지만 자체 문제 세트를 추가합니다.

"상속보다 컴포지션 선호"와 같은 일반적인 표현이 나오기 전에 지나치게 복잡한 상속 트리 (굉장히 재미 있고 완벽하게 작동했습니다)를 작성한 다음 나중에 수정하고 유지하기가 정말 어렵다는 것을 알았습니다. 그 말은 단지 전체 경험을 거치지 않고 그러한 개념을 배우고 기억할 수있는 대안적이고 간결한 방법을 가지기 때문입니다. 그러나 상속을 많이 사용하려면 열린 마음을 유지하고 그것이 얼마나 잘 작동하는지 평가하는 것이 좋습니다 상속을 많이 사용하고 최악의 학습 경험이 될 수 있습니다.

다른 답변과 달리 이것은 상속 대 구성과 관련이 없습니다. 상속 대 구성은 클래스 구현 방법에 대한 결정입니다. 인터페이스와 클래스는 그 전에 오는 결정입니다.

인터페이스는 모든 OOP 언어의 일류 시민입니다. 클래스는 보조 구현 세부 사항입니다. 새로운 프로그래머의 마음은 인터페이스 전에 클래스와 상속을 소개하는 교사와 책에 의해 심하게 뒤 틀립니다.

핵심 원칙은 가능할 때마다 모든 메소드 매개 변수 및 리턴 값의 유형이 클래스가 아닌 인터페이스 여야한다는 것입니다. 이를 통해 API가 훨씬 유연하고 강력 해집니다. 대부분의 시간, 메소드 및 호출자는 처리하는 객체의 실제 클래스를 알거나 신경 쓸 이유가 없습니다. API가 구현 세부 사항에 대해 무의미한 경우 아무 것도 깨지 않고 구성과 상속을 자유롭게 전환 할 수 있습니다.

누군가가 하나의 특정 접근법이 모든 경우에 가장 좋다고 말할 때마다 동일한 의약품이 모든 질병을 치료한다고 말하는 것과 같습니다.

상속 대 구성은 is-a vs has-a 문제입니다. 인터페이스는 일부 상황에 적합한 또 다른 (3 차) 방식입니다.

상속 또는 is-a 논리 : 새 클래스가 공개적으로 공개 될 경우 새 클래스가 동작 할 때 사용하고 이전 클래스와 같이 (외부 적으로) 완전히 사용됩니다. 이전 클래스의 모든 기능은 ... 상속합니다.

컴포지션 또는 기본 논리 : 새 클래스가 기존 클래스의 기능을 공개적으로 노출하지 않고 내부적으로 기존 클래스를 사용해야하는 경우 컴포지션을 사용합니다. 즉, 이전 클래스의 인스턴스를 멤버 속성 또는 새 변수. (이것은 사유 재산이거나 유스 케이스에 따라 보호되거나 기타 일 수 있습니다). 여기서 중요한 점은 이것이 원래 클래스 기능을 공개하고 공개하지 않으려는 유스 케이스라는 것입니다. 상속의 경우에는 상속 클래스를 통해 공개합니다. 새로운 수업. 때로는 하나의 접근법이 필요하고 때로는 다른 접근법이 필요합니다.

인터페이스 : 인터페이스는 또 다른 유스 케이스를위한 것입니다. 새로운 클래스가 기존 클래스의 기능을 부분적으로 완전히 구현 하지 않고 공개하기 를 원할 때 입니다. 이를 통해 기존 클래스와는 완전히 다른 계층의 새 클래스를 가질 수 있으며 일부 측면에서만 이전 클래스처럼 작동합니다.

클래스로 표현 된 생물을 분류하고 기능으로 표현 된 기능을 가지고 있다고 가정 해 봅시다. 예를 들어 새에는 Talk (), Fly () 및 Poop ()이 있습니다. Class Duck은 모든 기능을 구현하면서 Bird 클래스를 상속합니다.

여우는 분명히 날 수 없습니다. 따라서 모든 기능을 갖도록 조상을 정의하면 자손을 올바르게 파생시킬 수 없습니다.

그러나 Takeoff (), FlapWings () 및 Land ()를 포함하는 인터페이스를 사용하여 각 호출 그룹을 나타내는 기능을 그룹으로 나누면 Fox 클래스에서 ITalk 및 IPoop의 함수를 구현할 수 있습니다 그러나 그렇지 않습니다. 그런 다음 특정 인터페이스를 구현하는 객체를 허용하도록 변수와 매개 변수를 정의한 다음 해당 인터페이스를 사용하는 코드는 호출 할 수있는 것을 알고 다른 기능도 확인해야하는 경우 항상 다른 인터페이스를 쿼리 할 수 ​​있습니다. 현재 객체에 대해 구현되었습니다.

이러한 각 접근 방식은 최상의 경우 유스 케이스를 가지고 있으며 모든 경우에 대해 최상의 접근 방식은 없습니다.

엔터티 구성 요소 아키텍처와 함께 작동하는 게임, 특히 Unity의 경우 게임 구성 요소의 상속보다 구성을 선호해야합니다. 훨씬 유연하며 게임 엔티티가 상속 트리의 다른 잎에있는 두 가지를 "하게"하려는 상황에 빠지지 않습니다.

예를 들어, 상속 트리의 한 분기에 TalkingAI가 있고 다른 별도의 분기에 VolumetricCloud가 있고 말하는 클라우드를 원한다고 가정하십시오. 깊은 상속 트리로는 어렵습니다. 엔터티 구성 요소를 사용하면 TalkingAI 및 Cloud 구성 요소가있는 엔터티 만 만들면됩니다.

그러나 이것이 볼륨 클라우드 구현에서 상속을 사용해서는 안된다는 의미는 아닙니다. 이에 대한 코드는 상당하며 여러 클래스로 구성 될 수 있으며 필요에 따라 OOP를 사용할 수 있습니다. 그러나 모든 것이 단일 게임 구성 요소에 해당합니다.

참고로, 나는 이것에 대해 몇 가지 문제를 겪습니다.

나는 일반적으로 기본 클래스 (주로 추상화 됨)를 만들고 객체 상속을 사용하여 다양한 다른 객체와 동일한 기능을 공유합니다.

상속은 코드 재사용을위한 것이 아닙니다. is-a 관계 를 설정하기위한 것 입니다 . 이것들은 많은 시간이 필요하지만 조심해야합니다. 두 모듈이 동일한 코드를 사용해야한다고해서 하나의 모듈이 다른 모듈과 동일한 유형이라는 의미는 아닙니다.

예를 들어, List<IWeapon>다른 유형의 무기를 갖고 싶다면 인터페이스를 사용할 수 있습니다 . 이런 식으로 모든 무기에 대해 IWeapon 인터페이스와 MonoBehaviour 서브 클래스를 모두 상속 할 수 있으며 다중 상속이없는 문제를 피할 수 있습니다.

인터페이스가 무엇인지 또는 무엇을 이해하지 못하는 것 같습니다. OO에 대해 10 년 이상 생각하고 정말 똑똑한 사람들에게 질문하는 것은 인터페이스로 아하 순간을 가질 수 있다는 것이 었습니다. 도움이 되었기를 바랍니다.

가장 좋은 방법은 조합을 사용하는 것입니다. 내 OO 마인드 모델링에서 세상과 사람들은 예를 들어 말할 수 있습니다. 영혼은 마음을 통해 몸과 연결됩니다. 마음은 영혼 (지능을 고려한다)과 그것이 몸에주는 명령 사이의 인터페이스이다. 신체에 대한 마음의 인터페이스는 기능적으로 말하면 모든 사람에게 동일합니다.

세상과 인터페이스하는 사람 (신체와 영혼) 간에도 같은 비유가 사용될 수 있습니다. 몸은 마음과 세상의 경계입니다. 모두가 같은 방식으로 세상과 인터페이스합니다. 유일한 독특 성은 우리가 세상과 상호 작용하는 방법, 즉 우리가 세계에서 인터페이스 / 상호 작용하는 방법을 결정하기 위해 마음을 사용하는 방법입니다.

인터페이스는 단순히 OO 구조를 다른 다른 OO 구조와 서로 다른 속성 / 매개로 서로 협상 / 매핑해야하는 서로 다른 속성을 갖는 다른 OO 구조와 관련시키는 메커니즘입니다.

따라서 마음을 열고 함수를 호출하려면 open_hand를 호출하기 전에 필요한 모든 요구 사항을 구현하는 방법에 대한 지침과 함께 자체 API를 갖는 THAT를 사용하여 nervous_command_system 인터페이스를 구현해야합니다.