이번에 다룰 패턴은 Prototype 패턴이다. 이 패턴은 인스턴스를 생성할 때 사용하는 패턴 중 하나인데, 객체를 복사하는 방식으로 인스턴스를 생성해 낸다. 마치 만화 나루토에서 나오는 그림자 분신술 같은 느낌이다. 일단 UML을 한번 살펴보자
UML
Prototype을 상속받아 createClone() 메소드를 구현하는 ConcretePrototype으로 UML이 구성되어있다. 상당히 심플한 느낌의 UML이다. 원형을 하나 들고 있고, 들고있는 원형이 Prototype을 상속받아 createClone() 메소드를 구현한 상태라면 Client에서 원할 때 원형으로 클론을 만들어 사용할 수 있다.
왜 사용하나?
사실 인스턴스를 만드는 방법은 익히 일고있듯이 new Somthing() 을 이용하여 인스턴스를 만들면 그만이다. 그런데 왜 Prototype 패턴이라는 것 만들어서 사용해야 하는지 궁금할 수 있다. 책에서는 3가지 정도 상황에 대해서 이야기해주는데, 다음과 같다.
1. 종류가 너무 많아서 클래스로 정리할 수 없는 경우
2. 클래스로부터 인스턴스 생성이 어려운 경우
3. Framework와 생성하는 인스턴스를 분리하고 싶은 경우
3번은 적절했던 상황이 없어서 이해가 잘 되지 않지만, 2번은 주로 사용자가 커스텀해서 만든 도형을 저장하고 사용하고 싶을 때 사용하는 예제를 이용하여 많이 설명한다. 비교적 다른 경우보다 훨씬 와닿았던 1번을 좀 더 자세하게 예시를 들어 설명해볼까 한다.
일단 게임을 예시로 들어보자, 상점이 있고 여러 가지 아이템을 판매한다. 게임에서는 상점의 종류가 하나 일 수도 있지만 마을마다 여러 NPC가 다양한 아이템을 팔 수 있다. 이럴 때 각 상점 NPC마다 소스 안에서 파는 아이템의 판매를 if를 이용하여 소스코드 안에서 직접 관리하는 것보다. 각 NPC가 아이템 클래스들의 최상위 클래스 리스트를 통해 미리 생성된 아이템 원형들을 리스트로 가지고 있게 하고, 유저가 아이템 구매 의사를 밝혔을 때 해당 인덱스의 아이탬 원형에서 Clone을 생성하여 사용자에게 넘겨주는 모듈을 만들어두면, 새로운 NPC들을 만들기가 더 수월해질 것이다.
위 코드와 비슷한 비교가 될 것이다. 하나는 일일이 itemNum을 비교하고(스위치를 사용해도 됨) 있지만 오른쪽 부분은 vector를 통해 관리했고, 어느 아이템이 들어와도 return 하는 부분의 소스코드는 변하지 않기 때문에 모듈화를 하기도 편하고 코드를 재사용할 수 있다. 심지어, 아이템 개수가 많아졌을 때 왼쪽보다 오른쪽이 훨씬 더 관리하기 편해질 것이다.
소스 코드
이번에는 바쁜일이 좀 있어서 직접 소스코드를 제작하지는 못했다. 위키피디아에 공유된 소스코드를 gist를 이용하여 가져왔다. 추후 직접 소스코드를 제작하여 업데이트하도록 하겠다.