DesignPatternSmalltalkCompanion:2.3

2.3 장면 3: 데이터베이스 스키마와 Dream

몇 주 후 돈은 MegaCorp 회사 복도에서 제인과 마주친다.

돈:	제인! 지난번에 Interpreter 패턴을 알려줘서 고마워. 덕분에 QueryStrategy를 Abstract-ReimbursementStrategy의 또 다른 서브클래스로 빌드(build)할 수 있었어. 패턴에서 말한 대로 파서(parser)와 파스 노드(parse node)의 계층구조를 빌드해서 특정 원칙이 적용되었는지 결정하기 위해 사용했거든. 패턴을 이해하고 나니 정말 간단하던걸.
제인:	잘됐네. 도움이 됐다니 기쁜걸.
돈:	그 뿐만 아니라 시스템 내에 다른 패턴들도 찾기 시작했어. 나도 알지 못했는데 [디자인 패턴]에 소개된 패턴을 우리가 이미 몇 가지를 쓰고 있더라구. 예를 들어 Policy 클래스에는 현장에서 일하시는 분들에게 적용되는 사전 구성된 표준 문안 버전이 여러 개가 있었어. 그들이 새로운 Policy 를 만들길 원하면 그들은 기존 표준 문안 버전을 선택해 시스템이 그것을 복사하도록 시키지. 알고 보니 Prototype 패턴이더라구. 패턴을 읽고 나니 바로 이해가 됐어. 사실 패턴에서 "Prototype Manager" 라는 발상이 마음에 들어서 우리 설계에도 이용하게 됐어.
제인:	놀라운 일도 아냐. 책에서는 디자인 패턴의 문제에 대해 가장 공통되고 많이 수용되는 해법의 일부를 실어 놨거든. 계속해서 재발견될 것이라 보는 편이 옳아.
돈:	또 한 가지 재미있는 점은 우리 코드에서 패턴을 발견하게 된 후로 내가 사람들에게 이제부터 패턴의 약칭 사용하자고 설득했어. 이제 "그 클래스는 Decorator일 뿐이야" 아니면 "여기 템플릿 메서드(Template Method)를 여기 사용하는 게 어때?"라고 약칭으로 서로 대화하고 있어.
제인:	맞아, 그 점이 디자인 패턴의 가장 귀중한 부분 중 하나야: 설계자들이 서로 의사소통할 수 있는 공통된 단어를 제공하는 거지. 이제 작업할 용어집이 동일하니까 설계에 대해 이야기하는 것도 수월해지고 있어.
돈:	나도 동의해. 디자인 패턴으로 인해서 팀이 일하는 방법이 바뀌었어. 넌 요즘에 무슨 작업을 하고 있어?
제인:	사실 지난 수개월 간 작업해온 관계형 데이터베이스 액세스 프레임워크를 기록하고 있어. 설계에 사용된 디자인 패턴을 내가 쓰는 시스템의 기록문서에서 일부로 쓸 계획이야.
돈:	한 번 보여줄 수 있어?!
제인:	그래. 화이트보드를 봐. [둘은 제인의 칸막이 사무실로 가 제인이 화이트보드에 그려진 다이어그램을 가리킨다] 여기서 시작해볼게. [ForeignKeyProxy라는 이름의 클래스를 가리킨다] 이 클래스는...

돈:	[제인의 말을 가로채며] 클래스 이름만 봐도 알아볼 수 있겠는걸. 이건 Proxy야. 즉 실제 객체가 로드(load)될 때까지 다른 객체를 대신 실행시키지. 그치?
제인:	너 이제 완전히 이해했구나? 맞아. 객체는 데이터베이스 테이블에 Foreign key 를 계속 보유하고 있어. 필요시에 그 테이블로부터 실제 객체를 인스턴스화시키도록 DatabaseBroker 와 같이 실행하면 실제 객체로 대체되지.
돈:	음, 그건 클래스 이름으로 확실히 드러나는군. 이 설계에 또 어떤 패턴을 사용했어?
제인:	전체 서브시스템에서 Facade 역할을 하는 DatabaseBroker 클래스가 있어. 클래스의 클라이언트들이 서브시스템의 상세내용을 볼 필요가 없음을 의미하지; 단지 이 클래스의 public 인터페이스를 통해 실행될 뿐이야. 그리고 여기 DatabaseConnection 클래스는 Singleton이지. 이건...
돈:	시스템에는 해당 클래스의 인스턴스가 한 번에 하나만 존재한다는 걸 의미하지. 그럼 나머지 클래스들은? 거기에 해당하는 패턴이 없을까?
제인:	[씩 웃으며] 응, 없어. 디자인 패턴은 알고 나면 빠지기가 쉬워. 어떤 때는 패턴이 없는데도 보이기 시작해. 디자인 패턴이 모든 문제를 해결해주진 못할 거야; 단지 좀 더 공통으로 나타나는 문제에 해법을 찾도록 도와줄 뿐이지. 그나저나 너희 팀에서 사용자 인터페이스 클래스의 문서화를 시작할 참이라고 들었는데?
돈:	맞아. 혹시 그 클래스에서도 패턴을 찾아봐야 할까? 하지만 대부분이 VisualWorks GUI 빌더(VisualWorks GUI builder)로 빌드했는데. 우리가 만든 클래스를 몇 개 추가하긴 했지만 대부분은 도구(tools)에서 제공하는 것들을 이용했거든.
제인:	하지만 패턴은 기존 도구와 애플리케이션이 어떻게 작동하는지 설명하기에 좋은 방법이야. 예를 들어 VisualWorks의 ApplicationModel 클래스는 창에서 다른 뷰(View)들 간의 Mediator 처럼 행동하거든. 그리고 VisualWorks 가 와 모델(Model) 간 업데이트를 다루는 방법은 Observer 패턴을 구현한 거야.
돈:	있잖아, 우리 시스템의 몇 가지 측면을 그렇게 설명하면 도움이 될 것 같아. 우리 이야기를 바탕으로 정리해보면, 새로운 설계를 빌드하거나 다른 설계자들과 설계 선택권에 대해 이야기할 때, 또는 기존 설계를 문서화시킬 때 패턴을 이용하면 좋겠다는 결론이 나오네. 그렇지?
제인:	정확해. 그건 그렇고, [디자인 패턴] 책은 언제쯤 돌려받을 수 있을까?
돈:	[웃으며] 다 읽고 나면 줄게.