상속 vs 컴포지션

OOP를 재사용성을 중요시하는 이유

  • Don’s reinvent the wheel
  • 설계와 코딩에 드는 시간을 절약
    • 허나 프로그램이 미래에 어떻게 변할지 완전히 예측 불가
    • 아날로그 벽시계를 상속받아 디지털 손목시계를 만든 예
    • 오토바이로부터 자동차를 만드는 예
  • 테스트에 걸리는 시간을 절약
    • 버그가 없는 경우는 없기때문에 결국에 테스트를 하게됨
    • 자식클래스를 만들게될때 부모 클래스를 수정하는 경우가 발생함
  • 관리 비용 절약
    • 관련된 코드가 모두 한 파일 안에 있음

상속 vs 컴포지션 선택시 4가지 기준

상속 vs 컴포지션

  • 둘 다 재사용성이 목적
  • 가능/불가능의 측면에서만 보면 많은 경우에 둘 다 사용가능

컴포지션을 상속으로 바꾼예

  • 컴포지션 : waterspray,sprayhead, spraybottle
  • 상속 : waterbottle <- waterspray

상속을 컴포지션으로 바꾼예

  • 상속 : person <- teacher
  • 컴포지션 person, person을 가지는 teacher

고르는 네가지 기준

  1. 기계상의 차이 때문에 하나를 골라야 할 때
  2. 용도 때문에 상속을 고를 수밖에 없을 때
  3. 관리의 효율성을 고려할 때
  4. 그 외 일반적인 상황

기계상의 차이 때문에 하나를 골라야 할 때

상속과 메모리

  • 상속에는 메모리는 하나의 덩어리
  • 컴포지션은 개체생성시 여러 덩어리

프로그램 실행 중 첫 번째 병목점

  • cpu와 메모리 사이의 데이터 전송
  • cpu에 고속의 캐시 메모리를 탑재해서 해결
  • 상속모델로 만들시 개체가 한 번에 캐시 메모리에 들어갈 가능성이 높음
  • 컴포지션 모델로 만들시 개체 내 부품 수 만큼 캐시메모리로 로딩할 가능성이 높음

프로그램 실행 중 두 번째 병목점

  1. new delete 는 둘 중에 하나는 무조건 느림
  2. 상속은 메모리 할당과 해제가 딱 한 번씩
  3. 컴포지션은 한 번 + 부품 수만큼씩

용도 때문에 상속을 고를 수밖에 없을 때

다형성 : 상속을 사용할 수 밖에없음

관리의 효율성을 고려할 때

  • 컴포지션 사용시 getter의 중복 사용이 생김
  • 상속을 사용하면 불편한 경우
    • 깊은 상속 관계 Class B를 고칠시에 자식 클래스를 모두 확인해야함

그 외 일반적인 상황

  • 상식적으로 생각할 것
  • has-a와 is-a 관계에 충실하자.
    • has-a : 컴포지션
    • is-a : 상속

엔티티 컴포넌트 시스템

  • entity component system
  • 코드 변경 없이 자유롭게 개체를 만들 수 있도록 하는게 목적
  • 아키텍처 패턴 중 하나
  • 게임 업계에서 많이 사용

GameObject class

GameObject
  Effect
    DustEffect
    WindEffect
  PhysicsObject
    Character
      AiCharacter
        Monster
      Player
      NPC
    Vehicle

요구사항 변경

  1. 요구사항이 자주 바뀔때 상속 시스템에서는 업무 효율성이 떨어짐
  2. 그래서 엔티티 컴포넌트 시스템이 등장함

ex

GameObject
  -ArrayList<Component>

Component
  +update()
  EntityComponent
  PhysicsComponent
  AiComponent
  ConntrollableComponent
  • 실제 플레이어 등의 클래스는 사라짐
  • 컴포넌트 들을 조합해서 플레이어나 NPC등을 만듦
  • EntityCompponent에는 위치 정보
  • PhysicsComponent : 물리 정보
  • 기획자가 사용하는 툴에서 셋팅 가능