작성한 질문수 32

7

안녕하세요,

우선 OOP 관점에서 클래스를 설계할 때,
상속을 이용할 것인지 아니면 부품(component)을 이용할 것인지 선택하게 됩니다.
대부분 Is-A 관계가 성리하면 상속을, Has-A 관계가 성립하면 Component로 만드는게 정석인데요.
예를 들면 "오크는 몬스터다 (Orc Is-A Monster)" 관계가 성립하니, 오크는 Monster를 상속받는게 타당하고,
"플레이어는 인벤토리를 갖고 있다 (Player Has-A Inventory)" 관계가 성립하니,
Player 클래스 안에 Inventory를 Component로 만드는 쪽이 좋습니다.

말씀대로 Component 패턴은 그냥 "기능들을 부품화 해서, 코드의 의존성을 줄이고 재활용성을 높인다"는 것이 핵심입니다.
그리고 사실 OOP에서는 이미 Component를 자연스럽게 사용을 하고 있는 것도 맞습니다.
그러니 어떻게 보면 Component의 상위 범위에 OOP가 있다고 볼 수도 있겠네요.

위의 예제에서 Animation, Skill, Physics는 정말로 다른 기능들이니
별도의 class로 빼서 관리하는 것이 매우 자연스럽지만,
경우에 따라서는 과연 Component로 빼는게 좋을지? 애매모호 한 경우도 있습니다.
예를 들면 입력을 받는 InputComponent, 이동을 관리하는 MovementComponent를 굳이 따로 파는게 좋을까요?
유니티 사용 문서에는 대부분 Update문 안에 KeyBoard의 키와 비교를 하고,
역시나 키 입력 값에 따라서 직접 좌표를 이동해버리는 경우가 많은데
이렇게 하더라도 뭐 딱히 문제가 있진 않습니다.
다만 이렇게 할 경우 Update문 안에 입력/이동과 관련된 코드들이 종속적으로 묶이게 되므로 (tightly coupled)
코드의 유연성이 떨어지게 되겠죠.
InputComponent, MovementComponent를 따로 파서 관리를 하게 될 경우,
코드의 종속성도 끊어주는 장점도 있는데다가, 코드의 유연성도 훨씬 더 좋아집니다.
예를 들어 갑자기 마우스 입력 기반으로 바꾸고 싶다면
InputComponent 인터페이스를 상속받은 MouseInputComponent로 대체하면 그만이고,
물리 영향을 받아 이동하도록 급히 바꾸고 싶다면
역시나 MovementComponent 인터페이스를 상속받은 PhysicsMovementComponent를 이용해서
부품을 갈아끼면 그만이죠.

결론적으로 OOP는 [객체 관점에서의 관리]에 초점이 맞춰졌다면,
Component 패턴의 철학 자체는 [기능의 부품화]에 맞춰져 있으니 약간 뉘앙스가 다르긴 합니다.

0

설명이 명쾌하네요~ ㅋ

0

ㄴ 감사합니다. 명쾌하게 이해가 되었습니다!!