항목 23 : 클래스 관계 - 파트 2 (난이도 6)

디자인 패턴은 재사용 가능한 코드를 작성하기 위한 도구이다. 이번 항목에서 디자인 패턴을 알아 볼 수 있겠는가? 

코드

class string; class Record; class PrimaryKey; class GenericTableAlgorithm { public: GenericTableAlgorithm( const string& table ); virtual ~GenericTableAlgorithm(); /* 성공했을 경우 true를 리턴하며, 1. 물리적으로 테이블 레코드를 읽는다. 2. 수행해야 하는 열인지 판단하기 위해 Filter를 실행한다. 3. 수행하는 열의 목록이 완료되었을때 각 열에 대해 ProcessRow를 호출한다. */ bool Process(); private: /* 열을 처리해야 한다면 true를 리턴한다. */ virtual bool Filter( const Record& ); /* 처리하는데 포함되는 레코드마다 호출되어 지며 이 곳은 실제의 클래스가 틀별한 작업을 수행하는 곳이다. 이 말은 모든 처리되는 열이 두번 읽혀지지만 필요하고 효율성은 고려되지 않는다. */ virtual bool ProcessRow( const PrimaryKey& ) = 0; struct GenericTableAlgorithmImpl; GenericTableAlgorithmImpl* pimpl_; }; class MyAlgorithm : public GenericTableAlgorithm { /* virtual bool Filter( const Record& ); virtual bool ProcessRow( const PrimaryKey& ) = 0; 에 대한 정의를 한다. */ }; int main( void ) { MyAlgorithm a( "Customer" ); a.Process(); return 0; }

질문

1. 어떤 패턴을 사용 했는가? 왜 여기서 유용한가?

2. 근본적인 디자인의 변경없이 당신이라면 어떻게 완성하겠는가? pimpl_ 멤버의 목적은 무엇인가?

3. GenericTableAlgorithm의 의무사항은 무엇인가? 하나 이상이라면 더 잘 포장하는 방법이 무엇인가?

분석

1. 앞의 예제는 Template Method Pattern 을 사용 했으며, DB 접근 후 처리 하는 이 과정, 즉 일 처리 알고리즘 자체는 변하지 않는 틀이고, 그 세부 구현은 사용자에게 맞김으로써, 세부구현 대처에 유용하게 쓸 수 있기 때문에 사용 된 것으로 본다.

관련 링크 : http://www.ikpil.com/689

2. bool 형 반환보다는 좀더 세분화된 반환 타입을 결정하고, 세분화된 것으로 반환되어 지는게 좋을 듯 싶으며, pimpl_ 멤버의 목적은 클래스의 데이터가 추가되거나 삭제 되어 진다 하더라도, 재컴파일을을 하지 않아도 되며, 성가신 구조로 처리해야 할 경우, 좀 더 편한 모듈화 규현이 가능해 진다.

3. 현재의 의무사항으로는, 첫째, 알고리즘 틀을 제공해야 하며, 둘째, 그 틀에서 어떤것을 사용되는지 알려야 한다. 한 클래스의 의무를 두개를 지고 있기 때문에, 각 의무의 책임자를 분리하여, 사용 한다면, 보다 좋은 효과를 얻을 수 있을 것이므로, 다음과 같이 짜야 한다.

Template Method Pattern 심화 코드

/* 파일 : GenericTable.h */ #include <string> using std::string; class GTAClient; class GenericTableAlgorithm { public: GenericTableAlgorithm( const string& table, GTAClient& worker ); virtual ~GenericTableAlgorithm(); bool Process(); private: struct GenericTableAlgorithmImpl; GenericTableAlgorithmImpl* pimpl_; }; /* 파일 : GTAClient.h */ class Record; class PrimaryKey; class GTAClient { public: virtual ~GTAClient() = 0; virtual bool Filter( const Record& ); virtual bool ProcessRow( const PrimaryKey& ) = 0; }; /* 파일 : GTAClient.cpp */ #include "Record.h" // 관련이 있어야 한다. bool GTAClient::Filter( const Record& ) { return true; } /* 파일 : MyWorker.h 또는 hpp */ #include "GTAClient.h" class MyWorker : public GTAClient { // Filter() 와 ProcessRow를 구현하기 위해 재정의 한다. }; /* 파일 : main.cpp */ #include "GenericTable.h" #include "MyWorker.h" int main( void ) { GenericTableAlgorithm a( "Customer", MyWorker() ); a.Process(); return 0; }

 이런 코드로 짤 수 있겠다. 얻게 되는 이점으론

1. GenericTableAlgorithm의 확장 인터페이스들 즉, Filter와 ProcessRow 말고도 더 제공될 인터페이스가 있다 하더라도, GenericTableAlgorithm.h 는 고립되어 있기 때문에, 그 영향을 받지 않는다.
2. GenericTableAlgorithm의 인터페이스들의 매개변수가 변경되거나, 추가되어지거나, 디폴트매개변수로 바뀌더라도, GenericTableAlgorithm는 고립되어 GTAclien 관련된것만 재컴파일 영향을 받을 것이다.
3. GenericTableAlgorithm에서 사용되는 일꾼을 Filter() 와 ProccesRow()만 제공 되어 진다면, 다른 일꾼으로 교체가 쉽게 이루어 질 수 있다.

로 들 수 있다. 하지만 이것이 좋은것만은 아니다. 구조가 좀 복잡해 지기 때문이다. 필요한것 외로 복잡해진 구조는 오히려 과소비임을 알아야 한다.

중세 영국의 철학자이자 프란체스코 수도원의 수도사였던 윈리엄 오캄(William of Ockham(혹은 Occam), ca. 1285-1349)이 자주 했던 말이 떠올를 것이다.

"불필요하게 복잡한 의견을 제시해서는 안된다"

이 인용구는 오캄의 면도날 이라 불린다. 싸이트에 꼭 가 보아 그림을 보았으면 좋겠다.

이렇게 작업해 보니, GenericTableAlgorithm 이 함수로 보이게 될 것이다. 왜냐하면 하는 일은 워커와 문자열만 받아서 처리 하면 되기 때문이다.

이때 워커를 특화된 작업이라고 볼때, 특화 될 수 있는 일반적인 함수로 만들어 보다 깔끔하게 만들 수 있을 것이다.

template <class GTACworker> bool GenericTableAlgorithm( const string& table ) { GTACworker worker; // 처리.. }; /* 파일 : main.cpp */ #include "MyWorker.h" int main( void ) { GenericTableAlgorithm<MyWorker>( "Customer"); return 0; }

 Template Method Pattern 이 보다 깔끔해진 구조로 변경 됨을 볼 수 있다. 모든 것이 이렇게 될 순 없지만, 먼저 함수가 클래스보다 더 보기가 편하므로 이것을 사용하다가 어쩔수 없을 때, 클래스를 생성하는게 좋다.

총평

오캄의 면도날로 잘라버린 결과물은 복잡해 질수 있는 패턴이나, 클래스 사용보단 일반적인 함수를 이용하여 처리 되는 것이 더 보기가 깔끔해 질 수 있다고 나를 위협한다. 이제부터 나도 오캄의 면도날^[각주:1]을 사용 하겠다는 다짐을 갖게 된다.

C++은 지금의 나로선 정말 그 바닥이 보이질 않는 언어이다. 프로그래머의 길에서 보람을 찾는 날 이였다.

1. 이런 비유는 이해하기가 훨씬 유연해 지는 초석이 된다. 완전 사랑해! [본문으로]