[게임프로그래밍패턴] 디커플링 패턴 - 컴포넌트

문제.

커플링과 코드 길이 문제는 서로 악역향을 미친다. 

if (collidingWithFloor() && (getRenderState() != INVISIBLE)) {
	playSound(HIT_FLOOR);
 }

이 코드를 문제없이 고치려면 물리(collidingWithFloor), 그래픽(getRenderState), 사운드(playSound)를 전부 알아야 한다.

 

이 문제를 고치기 위해 한 덩어리였던 Bjorn 클래스를 분야에 따라 여러 부분으로 나누면 된다. 예를 들어 사용자 입력에 관련된 코드는 InputComponent 클래스로 옯겨둔 뒤에, Bjorn 클래스가 InputComponent 인스턴스를 갖게한다. 

 

이러고 나면 컴포넌트들을 묶는 얇은 껍데기 코드 외에는 Bjorn 클래스에 남는게 거의 없게 된다.

컴포넌트 클래스들은 서로 디커플링 되어 있다.

 

예제코드

class Bjorn {
public:
	int velocity;
	int x, y;

	void update(World& world, Graphics& graphics) {
		input_.update(*this);
		physics_.update(*this, world);
		graphics_.update(*this, graphics);
	}

private:
	InputComponent input_;
	PhysicsComponent physics_;
	GraphicsComponent graphics_;
};

class InputComponent {
public:
	void update(Bjorn& bjorn) {
		switch (Controller::getJoystickDirection()) {
		case DIR_LEFT:
			bjorn.velocity -= WALK_ACCELERATION;
			break;

		case DIR_RIGHT:
			bjorn.velocity += WALK_ACCELERATION;
			break;
		}
	}

private:
	static const int WALK_ACCELERATION = 1;
};

주의사항

컴포넌트 패턴을 적용하면 클래스 하나에 코드를 모아놨을 때보다 더 복잡해질 가능성이 높다. 

코드베이스 규모가 크면 이런 복잡성에서 오는 손해보다 디커플링과 컴포넌트를 통한 코드 재사용에서 얻는 이득이 더 클 수 있다. 하지만 컴포넌트 패턴을 적용하기 전에 아직 있지도 않은 문제에 대한 해결책을 오버엔지니어링하려는 것은 아닌지 주의해야 한다.