디자인 패턴 - 타입 객체 패턴(Type object pattern)
의도 :
클래스 하나를 인스턴스별로 다른 객체형으로 표현할 수 있게 만들어, 새로운 '클래스들'을 유연하게 만들 수 있게 한다.
데이터는 게임 코드를 빌드하지 않고도 변경할 수 있어야 한다. 더 나아가 새로운 데이터를 만들고 수정하는 데에 프로그래머의 도움이 필요 없도록 한다.
예를 들어 수백 종의 몬스터를 전형적인 OOP 개념을 만들어내면, 몬스터의 하위 클래스가 너무나도 많아진다.
몬스터를 상속받는 하위 몬스터들을 계속 만들어내지 말고, 몬스터 공통의 동작인 몬스터 클래스와 종족을 나타내는 클래스를 따로 만들어서 구성하자.
이렇게 되면 종족 클래스는 몬스터의 '타입'을 정의한다. 각각의 종족 객체는 개념적으로 다른 '타입'을 의미한다.
그리고 설정 파일에서 읽은 데이터로 종족 인스턴스를 만들어낸다. 그러면 코드 상에서 클래스 상속으로 만들던 타입 시스템의 일부를 런타임에 정의할 수 있는 데이터로 옮긴 셈이다.
타입 객체(Type object)와 타입 사용 객체(Typed object) 클래스를 정의한다.
모든 Type object는 논리적으로 다른 타입을 의미한다.
Typed object는 자신의 타입을 나타내는 Type object를 참조한다.
타입 사용 객체는 타입 객체를 생성자에서 레퍼런스로 받고, 이 레퍼런스에서 초기값을 받거나 동작을 포워딩한다.
사용 :
나중에 어떤 타입이 필요할지 알 수 없거나(새로운 몬스터가 추가되는 등), 컴파일이나 코드 변경 없이 새로운 타입을 추가하거나 변경하고 싶을 때 사용한다.
주의 :
타입 객체를 직접 관리해야 함.
타입 별로 동작을 표현하기 어려움. 타입 종속적인 데이터를 정의하기는 쉬우나, 타입 종속적인 동작을 정의하기가 어렵다. 이를 위해서, 동작을 각각 구현한 함수를 정의하고 타입 객체가 적당한 함수 포인터를 저장하게끔 할 수 있다(마치 vtable처럼). 더 나아가 바이트코드 패턴이나 인터프리터 패턴을 사용하면 동작 정의를 데이터로 옮길 수도 있다.
팩토리 메서드 패턴을 통해 타입 객체에서 새로운 타입 사용 객체를 얻어올 수 있다. 이런 팩토리 메서드를 통하면 메모리 할당과 초기화를 동시에 처리할 수 있다.
객체 생성 과정을 제어하고 싶을 때, 커스텀 할당자나 오브젝트 풀 패턴을 이용해 객체가 메모리 어디에 생성될지를 제어한다.
타입 객체에 생성자 함수를 정의하면 이런 로직을 둘 곳이 생긴다. 초기화 제어권을 새로 생성되는 타입 사용 객체에 넘겨주기 전에 메모리 풀이나 커스텀 힙에서 메모리를 가져올 수 있다.
즉, 타입 사용 객체를 사용하는 유일한 방법인 타입 객체 클래스에 이런 로직을 둠으로써, 모든 타입 사용 객체를 정해놓은 메모리 관리 루틴을 따라 생성되도록 강제할 수 있다.
여기에 더해서, 상속으로 데이터를 공유할 수 있다.
여러 타입 객체가 속성 값을 공유할 수 있게 만들면 좋을 것이다. 타입 객체끼리의 상속 시스템을 직접 구현해볼 수 있다.
상위 타입 객체를 가질 수 있게해서 단일상속을 구현할 수 있다. 생성자에서 타입 객체를 만들 때, 상속받을 상위 타입 객체를 넘겨주면 된다. 생성 시 하위 객체는 상위 객체로부터 값을 받을지, 자기 값으로 오버라이드할 지를 제어하면 된다.
값을 확인할 때에 하위 객체가 동적으로 상위 객체로부터 확인하거나(당연하지만 느릴 것이다), 생성자에서 상위 속성을 전부 복사해놓고 확인할 수 있다(Copy-down).
프로토타입 패턴으로 타입 객체의 json을 짠다거나 할 수도 있을 것이다. 같은 문제의 다른 접근이다.
경량 패턴과 비슷하다. 여러 인스턴스가 데이터를 공유할 수 있게 한다는 점에서. 경량 패턴의 목표는 메모리 절약이며, 타입 객체 패턴은 조직화와 유연성에 집중한다.
타입 객체 패턴에서 타입 사용 객체가 자신의 타입 객체를 교체할 수 있다면, 상태 패턴의 역할도 겸한다고 볼 수 있다.
클래스 하나를 인스턴스별로 다른 객체형으로 표현할 수 있게 만들어, 새로운 '클래스들'을 유연하게 만들 수 있게 한다.
데이터는 게임 코드를 빌드하지 않고도 변경할 수 있어야 한다. 더 나아가 새로운 데이터를 만들고 수정하는 데에 프로그래머의 도움이 필요 없도록 한다.
예를 들어 수백 종의 몬스터를 전형적인 OOP 개념을 만들어내면, 몬스터의 하위 클래스가 너무나도 많아진다.
몬스터를 상속받는 하위 몬스터들을 계속 만들어내지 말고, 몬스터 공통의 동작인 몬스터 클래스와 종족을 나타내는 클래스를 따로 만들어서 구성하자.
이렇게 되면 종족 클래스는 몬스터의 '타입'을 정의한다. 각각의 종족 객체는 개념적으로 다른 '타입'을 의미한다.
그리고 설정 파일에서 읽은 데이터로 종족 인스턴스를 만들어낸다. 그러면 코드 상에서 클래스 상속으로 만들던 타입 시스템의 일부를 런타임에 정의할 수 있는 데이터로 옮긴 셈이다.
타입 객체(Type object)와 타입 사용 객체(Typed object) 클래스를 정의한다.
모든 Type object는 논리적으로 다른 타입을 의미한다.
Typed object는 자신의 타입을 나타내는 Type object를 참조한다.
타입 사용 객체는 타입 객체를 생성자에서 레퍼런스로 받고, 이 레퍼런스에서 초기값을 받거나 동작을 포워딩한다.
사용 :
나중에 어떤 타입이 필요할지 알 수 없거나(새로운 몬스터가 추가되는 등), 컴파일이나 코드 변경 없이 새로운 타입을 추가하거나 변경하고 싶을 때 사용한다.
주의 :
타입 객체를 직접 관리해야 함.
타입 별로 동작을 표현하기 어려움. 타입 종속적인 데이터를 정의하기는 쉬우나, 타입 종속적인 동작을 정의하기가 어렵다. 이를 위해서, 동작을 각각 구현한 함수를 정의하고 타입 객체가 적당한 함수 포인터를 저장하게끔 할 수 있다(마치 vtable처럼). 더 나아가 바이트코드 패턴이나 인터프리터 패턴을 사용하면 동작 정의를 데이터로 옮길 수도 있다.
팩토리 메서드 패턴을 통해 타입 객체에서 새로운 타입 사용 객체를 얻어올 수 있다. 이런 팩토리 메서드를 통하면 메모리 할당과 초기화를 동시에 처리할 수 있다.
객체 생성 과정을 제어하고 싶을 때, 커스텀 할당자나 오브젝트 풀 패턴을 이용해 객체가 메모리 어디에 생성될지를 제어한다.
타입 객체에 생성자 함수를 정의하면 이런 로직을 둘 곳이 생긴다. 초기화 제어권을 새로 생성되는 타입 사용 객체에 넘겨주기 전에 메모리 풀이나 커스텀 힙에서 메모리를 가져올 수 있다.
즉, 타입 사용 객체를 사용하는 유일한 방법인 타입 객체 클래스에 이런 로직을 둠으로써, 모든 타입 사용 객체를 정해놓은 메모리 관리 루틴을 따라 생성되도록 강제할 수 있다.
여기에 더해서, 상속으로 데이터를 공유할 수 있다.
여러 타입 객체가 속성 값을 공유할 수 있게 만들면 좋을 것이다. 타입 객체끼리의 상속 시스템을 직접 구현해볼 수 있다.
상위 타입 객체를 가질 수 있게해서 단일상속을 구현할 수 있다. 생성자에서 타입 객체를 만들 때, 상속받을 상위 타입 객체를 넘겨주면 된다. 생성 시 하위 객체는 상위 객체로부터 값을 받을지, 자기 값으로 오버라이드할 지를 제어하면 된다.
값을 확인할 때에 하위 객체가 동적으로 상위 객체로부터 확인하거나(당연하지만 느릴 것이다), 생성자에서 상위 속성을 전부 복사해놓고 확인할 수 있다(Copy-down).
프로토타입 패턴으로 타입 객체의 json을 짠다거나 할 수도 있을 것이다. 같은 문제의 다른 접근이다.
경량 패턴과 비슷하다. 여러 인스턴스가 데이터를 공유할 수 있게 한다는 점에서. 경량 패턴의 목표는 메모리 절약이며, 타입 객체 패턴은 조직화와 유연성에 집중한다.
타입 객체 패턴에서 타입 사용 객체가 자신의 타입 객체를 교체할 수 있다면, 상태 패턴의 역할도 겸한다고 볼 수 있다.
댓글
댓글 쓰기