Odpowiedź.

Historycznie modularność pojawiła się jako sposób dzielenia dużych projektów na niezależne części logiczne, aby zwiększyć czytelność, ponowne wykorzystanie kodu i podział odpowiedzialności między programistami. W C modularność realizuje się na poziomie plików — źródłowych (.c) i nagłówkowych (.h).

Problem, z którym borykają się programiści: jak zorganizować interakcję między częściami kodu, unikać powielania definicji, nie naruszyć enkapsulacji i uprościć kompilację.

Rozwiązanie — użycie separacji interfejsu i implementacji:

W pliku .h deklarowane są zewnętrzne funkcje, typy, struktury.
W pliku .c znajduje się implementacja.
Dla zmiennych globalnych używa się extern.
Dla „prywatnych” elementów — static.

Przykład struktury kodu modularnego:

// 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
", add(3, 4));
    return 0;
}

Kluczowe cechy:

Wyraźne oddzielenie interfejsu (.h) i implementacji (.c).
Użycie static do ukrycia implementacji.
extern pozwala dzielić zmienne i funkcje między modułami.

Pytania z podstępem.

Czy można zdefiniować zmienną z extern w pliku nagłówkowym i bezpiecznie używać jej w kilku modułach?

Nie! Zmienne globalne należy definiować tylko w jednym pliku .c, a w nagłówkach — tylko deklarować za pomocą extern. W przeciwnym razie wystąpią błędy linkowania z powodu „multiple definition”.

Czy konieczne jest dołączanie każdego pliku nagłówkowego przez #include tylko raz?

Konieczne jest otaczanie każdego pliku .h strażnikami dołączania (#ifndef/#define/#endif), w przeciwnym razie przy wielokrotnym dołączeniu wystąpi konflikt deklaracji i błędy kompilacji.

Czy można zrealizować czystą enkapsulację prywatnych danych struktury (opaque pointer) w C?

Tak. Tzw. „opaque pointer” pozwala ukryć szczegóły struktury przed użytkownikiem:

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

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

Typowe błędy i antywzorce

Pomyłki między deklaracją a definicją zmiennych.
Brak include guards.
Naruszenie enkapsulacji (ujawnienie prywatnych detali w nagłówku).

Przykład z życia

Negatywny przypadek

Cała logika zrealizowana w jednym długim pliku .c, powtarzający się kod, globalne zmienne kolidują, występują błędy linkowania.

Plusy:

Szybkie prototypowanie.

Minusy:

Słaba utrzymywaność, ryzyko konfliktów, trudność w debugowaniu.

Pozytywny przypadek

Kod zdekomponowany na moduły, używane są include guards, prywatne dane są zamykane przez opaque pointer.