[GPP]컴포넌트 패턴

 

초안 : 2020-05-05수정 : 2023-02-02

 

의도 

"한 개체가 여러 분야를 서로 커플링 없이 다룰 수 있게 한다."

 

3가지의 방식

 

1. 컨테이너 객체의 상태를 변경하는 방식

(ex 캐릭터(위치값)->(전달)->입력 컴포넌트 and 피직스 컴포넌트)

- 컴포넌트들은 서로 디커플링 상태를 유지한다.

    예를 들어 InputComponent에서 캐릭터의 속도를 변경하고, PhysicsComponent에서 그 값을 사용하면 이들 두 컴포넌트는 서로 몰라도 된다. 그저 캐릭터의 속도가 알 수 없는 무엇인가에 의해 변경되었다고 짐작만 할 수 있다.

 

- 컴포넌트들이 공유하는 정보를 컨테이너 객체에 전부 넣어야한다.

    예를 들어, 그래픽 관련 상태를 공유해야 하는데, 이런 상태를 다른 모든 컴포넌트가 접근 할 수 있는 컨테이너 객체로 올려 놓는다면, 객체 클래스가 지저분 해 질 수 있다.

(심지어 컴포넌트 조합에 따라 보이지 않는 객체에는 컨테이너 객체에 들어 있는 렌더링 관련 데이터가 메모리 낭비일 뿐이다.)

   

- 컴포넌트끼리 암시적으로 통신하다 보니 컴포넌트 실행 순서에 의존.

   사용자가 입력->물리->렌더링의 순서로 진행 되여야 할 때, 마지막 그래픽 컴포넌트를 먼저 업데이트하면, 캐릭터의 이번 프레임이 아닌, 이전 프레임 위치에 잘못 그리게 된다. 컴포넌트 개수와 코드가 많을 수록 이런 버그를 피하기 어렵다.

 

 

 

2. 컴포넌트가 서로 참조하는 방식

(ex 그래픽 컴포넌트(피직스 컴포넌트가 OnGround 상태인지?))

- 간단하고 빠르다.

   한 객체가 다른 객체 메서드를 직접 호출 해 통신한다. 컴포넌트는 자기가 참조하는 컴포넌트에서 제공하는 어떤 메서드라도 아무런 제한 없이 호출 할 수 있다.

 

- 두 컴포넌트(서로 참조하는 컴포넌트)가 강하게 결합하게 된다.

   아무런 제한이 없다 보니 생기는 단점이다. 다만 서로 통신하는 컴포넌트끼리만 커플링이 생기기 때문에 통자 클래스 형태일 때보다는 낫다.

 

 

3. 메시지를 전달하는 방식

(ex 컨테이너 오브젝트->(관련 메시지전달)입력컴포넌트, 피직스컴포넌트..등등)

- 하위 컴포넌트들은 디커플링 된다.

   상태 공유 방식에서 처럼 상위 컨테이너 객체를 통해서 통신하기 때문에, 컴포넌트들은 메시지 값과 커플링 될뿐 컴포넌트끼리는 디커플링 상태를 유지한다.

 

- 컨테이너 객체는 단순하다.

   무작정 메시지만 전달하면 된다. 특정 분야에 한정된 정보를 컨테이너 객체에 노출하지 않고도 컴포넌트끼리 주고 받을 수 있다.