항목 32 : 이름 검색과 인터페이스 - 파트 2 (난이도 9)

이번엔 클래스에 대하여 알아 보는 항목이다.

클래스란?

"클래스는 연관되어진 데이터와 데이터 처리 함수들의 모음을 정의한 것이다"

이제 질문의 시간을 갖어 보자. ① 어떤 함수들이 클래스의 "일부"일까? 그리고 ② 클래스의 인터페이스는 무엇으로 만들어 졌을까?

힌트

1. 확실히 non-static 멤버 함수들은 단단히 클래스와 연결되어 졌다. 그렇다면 static 멤버 함수들은과 자유(free) 함수들의 경우는 어떠한가?
2. 항목 31의 함축적 의미를 시간을 두어 생각해 보자.

분석

①,② 이 두 질문들의 대답을 좀더 심화 시켜 본다면,

• 이 대답이 C 형식의 개체지향 프로그래밍에 어떻게 적용 될까?
• C++의 Koening 검색이 어떻게 적용될까?, Myers 예는?
• 클래스 의존성을 분석하고 개체 모델을 디자인하는 방법에 어떻게 영향을 미칠까?

어찌보면, 어떤 질문에 더 좋은 해결법은 더 좋은 질문을 하는 것 일 수 있겠다. 이 더 좋은 질문들에 답하기 앞써, 클래스의 이름 검색과 인터페이스의 기초인, 어떤것이 클래스의 일부일까? 에 대한 질문에 답해 보자.

예제 1 (a)
#include <iostream> class CTEST { public: int GetVar( void ) const { return a; } public: CTEST() : a( 0 ) {} ~CTEST() { } private: int a; }; void Draw( const CTEST& rhs ) { std::cout << "CTEST::Draw() : " << rhs.GetVar() << std::endl; } int main( void ) { CTEST p; Draw( p ); return 0; }
 이 코드에서 Draw() 함수는 CTEST 클래스의 일부라고 봐야 하나? 아마도 열에 여덞명은 "아니오" 라고 대답을 할 것이다.  그리고 어떤 사람은 기본적으로 중요한 것을 께달게 된다. 만약 예제 1 (a) 의 int main() 함수를 제외하고 한 파일에 있다면 다음과 같은 코드와 두드러지게 다르지 않을 것이다.

예제 1 (b)
#include <iostream> class CTEST { public: void Draw( void ) { std::cout << "CTEST::Draw() : " << a << std::endl; } public: CTEST() : a( 0 ) {} ~CTEST() { } private: int a; }; int main( void ) { CTEST p; Draw( p ); return 0; }

...
..
.

 잠시동안 생각을 해보면, 한 파일에 이런 Draw()같은 것들이 제공되어 졌을 때, 예제 1 (a) 예제 2 (b)는 CTEST를 제공 받거나 언급되어지게 된다면, 모두 CTEST의 일부라고 봐도 될 것이다.

Effective C++ 에 보면, 진정한 OOP는 클래스안에 함수를 두는 것이 아닌, 클래스 외부에 둠으로써, 상속이나 기타 변경사항들에 있어, 좋은 점들을 설명하는 항목이 있으니 한번 참조 바란다.

다시 본론으로 들어와서, 이런 개념이 C 형식의 개체지향 프로그래밍에 어떻게 적용 시킬수 있을까? 다음 코드를 보도록 하자.
struct _iobuf { /*데이터는 여기에*/ }; typedef struct _iobuf FILE; FILE* fopen( const char* filename, const char* mode ); int fclose( FILE* stream ); int fseek( FILE* stream, long offset, int origin ); long ftell( FILE* stream ); /* 기타 ... */
  이 코드를 볼수 있듯이 fopen fclose fseek, ftell 은 FILE의 인터페이스라 볼수 있으며, 이렇게 사용 할 수 있을 것이다. 우리는 알게 모르게 OO적인 마인드로 코딩을 하고 있었던 것이다.

이런 "제공" 되거나, "언급" 되는 것을 "일부" 라고 봤을 때 p.176 ~ p.177과 항목 31은 Exceptional Koenig 이 어떻게 적용 되는지를 알려준다.

요약하자면, 컴파일러는 강제로 둘 사이에 강한 관계를 맺게 해준다는 것이다. Koenig 검색에 의하여 ㅋㅋ

하지만 이것을 좋게만은 바라 볼수가 없다. Myers 예를 든다면, "오히려 더 모호해 져서 햇갈리지 않느냐?"를 의미하는것 으로 보인다. 하지만, 여전히 독립적이고, 예상되는 사용들에 알맞다는 의미도 있다.

예상되는 사용들은 항목 31을 보는게 더 빠를 것이다.

요약하자만, 인터페이스 원칙(언급 되거나 제공 되어 졌다면 일부로 볼 수 있다.)이 Koenig 검색과 완전히 같은 방법으로 동작하는 것은 우연아니며, 매우 쓸만하다.

총평

사실 Koenig 검색법이 무척이나 안좋다고 생각하고 있었다. 하지만, 내가 요구하는 사용법에 딱 맞는 방법이고, 심하게 네임스페이스를 깨뜨리는 것이 아니므로, Koenig 검색 법은 쓸만하다.

책에선 클래스의 멤버 함수가 비멤버 함수보다 더 강한 관계를 맺고 있다고 설명하고 있다. 이 부분에 대해서 한번쯤 생각을 정리해 보는 것도 도움이 될 것이라 생각 된다.

이런 강한 관계는 OOP로 구분이 더 어려워 지는 부분도 있다고 EC++ 에 나와 있으니 참고하면 좋을 듯 싶다.

정리 하고 나니, 클래스를 만들 때 좀 더 생각을 하게 된다.