상속과 위임에 대한 가벼운 예제

게임을 만들고 싶어서 프로그래밍에 손을 댄 이후 계속 다른 일만 하다가, 1999년 즈음에 처음으로 게임을 만들게 된 적이 있었습니다.  같이 작업하던 후배는 "보드 게임은 게임에 속하지 않습니다!"라고 반항을 했지만 ㅡ.ㅡ;

서버를 작성하는데, 다른 게임을 만들 때 공통적으로 사용 될 요소들이 보이기 시작했습니다.  그래서, 미리 다음과 같은 분업을 시작했습니다.

[그림 1] 상속을 통해서 각 레이어에 알맞는 프로토콜을 분리하여 설계

• RoomProtocol: 게임과 관련없는 채팅방의 프로토콜 관리
• GameProtocol: 게임 로직과 관련 된 프로토콜 관리

소스가 한 결 간단하고 명료해 진 것을 보고 뿌듯한 마음에 자랑하고 싶은 심정이었습니다.  그러다가, 정말 다른 게임을 추가해야 하는 상황에 이르렀습니다.  그래서, 가볍게 [그림 2]와 같이 처리하였습니다.  RoomProtocol을 공유하면서 개발 기간 단축 뿐 아니라, 검증 및 테스트 기간도 덤으로 절약 할 수 있었습니다.

[그림 2] 새로운 게임의 등장

하지만, 바로 Game Protocol 사이에도 중복 요소가 마음에 걸립니다.  결국 [그림 3]과 같은 모양으로 리팩토링을 마쳤습니다.

[그림 3] 리팩토링 결과

그런데, 또 다른 게임을 추가하니 GameProtocol_Common에서 공통적으로 사용 할 수 없는 부분들이 생겨납니다.  그리고, 더 심각하게는 RoomProtocol 마저 공통적으로 사용 할 수 없는 부분이 발생하게 되었습니다.  문제는, 부모 클래스를 수정하면서 안정화 되었던 자식 클래스들이 상당한 영향을 받게 되는 것 입니다.

일정에 쫓기는 개발 현장에서 소스가 점점 더 복잡해 지고, 그렇게 한 참이 흐른 뒤에 결단을 내리게 됩니다.

"처음부터 다시 하자 ㅠ.ㅠ"

이번에는 상속 대신 위임을 통해서 프로토콜을 분리하고 재사용 할 수 있도록 설계를 변경하였습니다.

[그림 4] 위임을 통한 해법

필요한 프로토콜만 ProtocolList.Add()를 통해서 선택하면 되는 형태입니다.  이쯤 되니 일단은 만족스러운 결과물이 되었습니다.

다만, 유사한 프로토콜 사이에 생기는 중복코드는 여전히 상속으로 처리 되어 있는 곳도 있습니다.  그 밖에 실제 코드에서는 더욱 복잡한 문제들로 인한 구현 요소들이 있습니다.  여기서는 상속과 위임만 부각시켜서 설명했습니다.

상속이 더욱 자연스러운 경우에 대한 판단 근거는 http://ryulib.tistory.com/76 와 같습니다