답변.

역사적으로 모듈화는 대규모 프로젝트를 독립적인 논리적 부분으로 분할하여 가독성, 코드 재사용 및 개발자 간의 책임 분담을 높이기 위한 방법으로 등장했습니다. C에서 모듈화는 파일 수준에서 구현됩니다 — 소스 (.c) 및 헤더 (.h) 파일.

프로그래머가 직면하는 문제: 코드 부분 간의 상호 작용을 어떻게 조직하고 정의의 중복을 피하며, 캡슐화를 깨뜨리지 않고 빌드를 단순화할 것인가.

해결책은 인터페이스와 구현의 분리를 사용하는 것입니다:

.h 파일에서 외부 함수, 타입 및 구조체를 선언합니다.
.c 파일에서 구현을 제공합니다.
전역 변수에 대해서는 extern을 사용합니다.
'프라이빗' 엔티티에 대해서는 static을 사용합니다.

모듈화된 코드 구조 예:

// mymath.h
#ifndef MYMATH_H
#define MYMATH_H
int add(int, int);
#endif

// mymath.c
#include "mymath.h"
int add(int a, int b) { return a + b; }

// main.c
#include "mymath.h"
#include <stdio.h>
int main() {
    printf("%d\n", add(3, 4));
    return 0;
}

주요 특징:

인터페이스 (.h)와 구현 (.c)의 명확한 분리.
구현을 숨기기 위해 static 사용.
extern은 모듈 간에 변수를 및 함수를 나누도록 허용합니다.

의문이 있는 질문들.

헤더 파일에 extern으로 변수를 정의하고 여러 모듈에서 안전하게 사용할 수 있나요?

아니요! 전역 변수는 하나의 .c 파일에서만 정의해야 하며, 헤더 파일에서는 extern으로만 선언해야 합니다. 그렇지 않으면 'multiple definition'으로 인해 링킹 오류가 발생합니다.

각 헤더 파일을 #include를 통해 한 번만 포함해야 하나요?

각 .h 파일을 보호 매크로 (#ifndef/#define/#endif)로 감싸야 하며, 그렇지 않으면 여러 번 포함 시 선언 충돌과 컴파일 오류가 발생합니다.

C에서 구조체의 프라이빗 데이터에 대한 깨끗한 캡슐화를 구현할 수 있나요?

네. 이른바 'opaque pointer'는 사용자로부터 구조체의 세부 사항을 숨길 수 있습니다:

// mystruct.h
typedef struct MyStruct MyStruct;
MyStruct* create(void);
void destroy(MyStruct*);

// mystruct.c
struct MyStruct { int a; };

일반적인 오류 및 안티 패턴

변수의 선언과 정의의 혼동.
include guards의 부재.
캡슐화의 위반 (헤더에 프라이빗 세부사항을 노출).

실제 예시

부정적인 사례

모든 로직이 하나의 긴 .c 파일에 구현되어 코드가 중복되고 전역 변수가 충돌하며 링킹 오류가 발생합니다.

장점:

빠른 프로토타이핑.

단점:

낮은 유지보수성, 충돌 위험, 복잡한 디버깅.

긍정적인 사례

코드가 모듈별로 분해되고 include guards가 사용되며 프라이빗 데이터가 opaque pointer를 통해 숨겨져 있습니다.