项目实战一：计算器模块化设计

好，咱们终于到了第一个实战环节。说实话，我特别喜欢拿计算器来讲解模块化设计——为什么呢？因为它的逻辑足够简单，但又能把模块划分、接口设计、编译管理这些核心问题全给暴露出来。你想想看，一个加减乘除的计算器，小学生都懂，但要用C语言写出一个可维护、可扩展、可测试的版本，还真不是件容易事。

我记得刚入行那会儿，带我的老工程师跟我说过一句话：「写代码就像搭积木，每块积木都要能独立拿起来看。」当时我不太理解，直到后来接手一个几千行的单文件项目，改一个bug要翻半天代码……嗯，从那以后，我再也不敢写「大泥球」式的代码了。

1. 项目需求与模块划分

我们先明确一下这个计算器要做什么：

• 支持加、减、乘、除四种基本运算
• 输入和输出要分离——说白了，计算逻辑不能依赖具体的输入方式
• 每个运算模块独立成文件，方便单独测试和替换

基于这些需求，我建议把项目拆成下面几个模块：

为什么要这么分？我个人的习惯是：一个文件只做一件事。加减乘除各占一个文件，将来你要加一个「求余」运算，直接新建一个 mod.c 就行，完全不影响其他模块。这就是模块化的威力。

2. 接口设计：头文件怎么写

模块化编程的核心，就是接口要清晰。头文件里只放「别人需要知道的东西」，实现细节全部藏到 .c 文件里。

我们来看加法模块的头文件：

// add.h
#ifndef __ADD_H__
#define __ADD_H__

/**
 * @brief 加法运算
 * @param a 第一个操作数
 * @param b 第二个操作数
 * @return a + b 的结果
 */
double add(double a, double b);

#endif /* __ADD_H__ */

注意几个细节：

• 用了 #ifndef 防止重复包含——这是C语言的老规矩了
• 函数声明加了注释，说明参数和返回值
• 返回值用 double，因为除法可能产生小数

减法、乘法、除法的头文件结构完全一样，只是函数名不同。我建议你直接复制粘贴，然后改一下函数名和注释就行。别觉得这是偷懒——一致性本身就是一种设计。

3. 实现文件：把功能写清楚

加法模块的实现非常简单：

// add.c
#include "add.h"

double add(double a, double b)
{
    return a + b;
}

减法、乘法同理。但除法模块要小心：

// div.c
#include "div.h"

double divide(double a, double b)
{
    if (b == 0.0) {
        // 我曾经在项目里遇到过除零导致系统崩溃的事故
        // 从那以后，所有除法接口我都加了检查
        return 0.0;  // 实际项目中应该返回错误码或设置全局错误标志
    }
    return a / b;
}

这里我故意没做太复杂的错误处理——因为我们的输入输出是分离的，错误处理应该由调用方来决定。计算模块只负责「算」，不负责「报错给用户」。这就是职责分离。

4. 核心调度模块：把积木拼起来

现在我们有四块积木了，需要一个「调度员」来根据用户的选择调用对应的模块：

// calc.h
#ifndef __CALC_H__
#define __CALC_H__

typedef enum {
    OP_ADD = 1,
    OP_SUB,
    OP_MUL,
    OP_DIV
} Operator;

double calculate(double a, double b, Operator op);

#endif /* __CALC_H__ */

实现文件：

// calc.c
#include "calc.h"
#include "add.h"
#include "sub.h"
#include "mul.h"
#include "div.h"

double calculate(double a, double b, Operator op)
{
    switch (op) {
        case OP_ADD: return add(a, b);
        case OP_SUB: return sub(a, b);
        case OP_MUL: return mul(a, b);
        case OP_DIV: return divide(a, b);
        default:     return 0.0;
    }
}

你看，这个调度模块完全不知道输入是怎么来的，也不知道结果要输出到哪里。它只负责「根据操作符，调用对应的函数」。这就是模块化带来的好处——每个模块都可以独立测试。

5. 输入输出分离：主程序只做一件事

最后是主程序。它只负责两件事：获取用户输入，显示计算结果。

// main.c
#include <stdio.h>
#include "calc.h"

int main(void)
{
    double a, b;
    int op;

    printf("简易计算器 v1.0\n");
    printf("请输入第一个数: ");
    scanf("%lf", &a);
    printf("请输入第二个数: ");
    scanf("%lf", &b);
    printf("选择运算 (1:加 2:减 3:乘 4:除): ");
    scanf("%d", &op);

    double result = calculate(a, b, (Operator)op);
    printf("结果: %.2f\n", result);

    return 0;
}

嗯，这里要注意：如果将来你想改成从文件读取数据，或者改成图形界面，你只需要改 main.c 就行了，加减乘除的代码一个字都不用动。这就是「输入输出分离」的真正价值。

6. 项目结构总览

为了让你们更直观地理解模块之间的关系，我画了一张图：

7. 编译与测试

多文件项目怎么编译？我建议用 gcc 直接编译所有 .c 文件：

gcc -Wall -Wextra -o calculator main.c calc.c add.c sub.c mul.c div.c

或者你也可以先编译成目标文件，再链接：

gcc -c main.c
gcc -c calc.c
gcc -c add.c
gcc -c sub.c
gcc -c mul.c
gcc -c div.c
gcc -o calculator main.o calc.o add.o sub.o mul.o div.o

我个人习惯用第二种方式——因为改了一个文件只需要重新编译那个文件，再链接一下就行，省时间。尤其是项目大了以后，这个习惯能帮你省下不少喝咖啡的时间。

8. 扩展思路

这个框架搭好了，你想加功能就很简单：

• 加一个「求余」运算：新建 mod.c / mod.h，在 calc.c 里加一个 case
• 改成从文件读取输入：只改 main.c
• 加一个「历史记录」功能：新建 history.c / history.h，在 main.c 里调用

这就是模块化的魅力——每个模块都是独立的积木，你可以随时替换、添加、删除，而不影响其他部分。

好了，这个实战项目就讲到这里。代码我已经全部贴出来了，建议你亲手敲一遍，然后试着加一个「求余」模块。只有自己动手写过，才能真正理解模块化设计的好处。

---