준형's 블로그 :: API or MFC

우리는 윈도우 프로그래밍을 할 때, 엄청난 빈도로 파일을 열거나 저장한다.
일반적인 워드프로세서나 포토샵, 뮤직플레이어 등을 볼 때,
오히려 파일을 열고 닫는 작업이 없는 프로그램을 찾는 것이 더 힘들 정도이다.

일반적으로 파일을 열 경우 우리는 아래와 같은 다이얼로그를 접하게 된다.

이 다이얼로그를 여는 방법에서 당연히 MFC와 API는 차이가 있다.
아래는 MFC 코드이다.

CFileDialog dlg(TRUE, NULL, NULL, OFN_EXPLORER | OFN_FILEMUSTEXIST, _T("All Files (*.*)|*.*||"), this);
if (dlg.DoModal() == IDOK)
::SetDlgItemText(*this, IDC_EDIT, (LPCSTR)dlg.GetPathName());

아래는 API 코드이다.

TCHAR path[MAX_PATH] = _T("");

OPENFILENAME ofn = {0,};
ofn.lStructSize = sizeof(ofn);
ofn.hwndOwner = *this;
ofn.hInstance = ::AfxGetInstanceHandle();
ofn.lpstrFilter = _T("All Files (*.*)\0*.*\0\0");;
ofn.lpstrFile = path;
ofn.nMaxFile = MAX_PATH;
ofn.Flags = OFN_EXPLORER | OFN_FILEMUSTEXIST;
if (::GetSaveFileName(&ofn))
::SetDlgItemText(*this, IDC_EDIT, path);

MFC는 3줄인데 반해 API는 11줄이나 된다.
두 코드는 정확이 똑같은 모양과 특성의 다이얼로그를 만든다.

물론 그렇다고 위의 상황으로 MFC가 무조건 우월하다는 것은 아니다.
개인적으로 프로젝트 상에서는 후자인 API를 자주 쓴다.
그 이유는 본인의 주 업무가 ATL/COM 관련 프로그래밍이기 때문에
MFC를 쓸 기회가 매우 적기 때문이다.

그러나 MFC를 이용해 테스트 코드를 짜는 빈도는 엄청나게 많다.
새로운 API나 클래스를 쓰거나 라이브러리의 기능 중 의심나는 부분이 있으면
테스트를 위해 어김없이 콘솔 프로젝트 또는 MFC 다이얼로그 프로젝트를 생성한다고 보면 된다.
이 때, 단순 테스트를 위해 후자와 같이 긴 코드를 만드는 것은 상당한 낭비라고 생각한다.
그래서 요즘에는 전자인 MFC 다이얼로그 코드를 많이 쓰게 되었다.

결국 MFC와 API는 우월성 관계 보다는
필요와 효율의 문제라는 것을 알 수 있다.