C++面向对象编程中类内混合用户I/O与业务逻辑是否属于不良实践

你在大一过程式编程阶段被反复强调的「业务功能逻辑与用户交互逻辑分离」的原则，在面向对象编程体系中不仅没有失效，反而是类设计的核心评判标准。把输入输出逻辑硬编码进承载业务规则的类中，属于典型的不良编程实践。很多人刚从过程式转到OOP时会觉得之前的解耦要求过时了，实际上你现在在Task类里硬塞cout的写法，和当初把计算逻辑、输入输出混在同一个main函数里的问题本质完全一样。

• 类的职责会严重跑偏。你设计的Task类本质是代表一道数学题的业务实体，核心职责应该是：生成随机运算数、匹配运算类型、存储题面信息、计算正确答案、校验用户提交结果的正确性。这些都和“题面怎么展示给用户、怎么读取用户输入”的交互规则完全无关。
• 代码复用性会被彻底锁死。现在printTask方法直接硬绑定控制台输出，意味着这个类只能用在命令行场景下。如果后续你要把项目改成网页答题、桌面弹窗、甚至导出成纸质练习题PDF，必须修改Task类的内部实现才能适配，完全违反“对扩展开放、对修改关闭”的开闭原则。
• 自动化测试会变得极其困难。现在你想给Task类写单元测试，一调用题目生成方法就会自动往控制台打印内容，根本没法在无交互的测试环境里自动校验题目生成、答案计算逻辑的正确性。

完全照搬你大一学的分层思路，只是把有状态的业务逻辑封装成类，把无状态的交互逻辑放到独立的模块里即可，具体操作可以结合你现有代码做这些调整：

• 把所有纯业务逻辑收回Task类内部，完全剥离所有输入输出调用：
  • 为类新增私有成员，存储当前生成的两个随机运算数、最终选用的运算类型，替代原来生成完数直接打印的逻辑。
  • 把原来printTask里的随机题目生成逻辑抽成独立的generateTask(operation op)方法，内部负责确定运算类型、生成随机数，结果存在类成员里，全程不碰任何输出流。
  • 给类加只读接口，比如getTaskDisplayText()，负责把当前题面拼成可展示的字符串，由上层逻辑决定是打到控制台、传到网页还是存成文件。
  • 完善checkifRight(double result)方法，只做纯数值比对校验，不负责读取用户输入。
• 把所有和用户交互相关的逻辑，放到独立的交互层（初期可以直接写在main函数里，后续规模变大可以抽成专门的ConsoleTaskUI类）：
  • 交互层只负责对接输入输出设备：拿到Task提供的题面字符串、调用cout打印；从cin读取用户输入的答案，转成数值后传给Task的校验方法；再把校验结果拼成语句打印给用户。

可以看一个拆分前后的代码对比：
原来的混合写法（存在业务和IO耦合的问题）：

void printTask(operation op){
    if(op == random)
        op = (operation)(rand() % 4);
    if(op == add)
        cout << getRand() << " + " << getRand() << endl;
    if(op == sub)
        cout << getRand() << " - " << getRand() << endl;
    // 其他运算分支逻辑同理
}

拆分后的Task类纯业务方法（无任何IO调用）：

class Task{
private:
    int min;
    int max;
    // 新增业务状态成员
    int a, b;
    operation current_op;
public:
    // 原有构造、setInterval、getRand方法不变
    void generateTask(operation op) {
        if(op == random)
            current_op = (operation)(rand() % 4);
        a = getRand();
        b = getRand();
    }

    string getTaskDisplayText() const {
        switch(current_op) {
            case add: return to_string(a) + " + " + to_string(b) + " = ?";
            case sub: return to_string(a) + " - " + to_string(b) + " = ?";
            case mult: return to_string(a) + " * " + to_string(b) + " = ?";
            case divis: return to_string(a) + " / " + to_string(b) + " = ?";
            default: return "";
        }
    }

    bool checkifRight(double result);
};

对应独立的交互层逻辑（完全不涉及业务规则计算）：

int main(){
    srand(time(NULL));
    Task math_task(15, 100);
    math_task.generateTask(operation::random);

    // 以下都是纯交互逻辑，不属于Task类
    cout << math_task.getTaskDisplayText() << endl;
    double user_ans;
    cin >> user_ans;
    cout << (math_task.checkifRight(user_ans) ? "回答正确" : "回答错误") << endl;
    
    return 0;
}

• 分离交互逻辑不等于要把类和交互完全隔离开，核心是要遵循依赖倒置原则：业务类（比如Task）不能反向依赖具体的交互实现。你完全可以为交互层写专门的类，但是交互层要持有Task类的实例，反过来调用Task的业务方法，而不是Task类自己主动调用cout/cin。
• 你在过程式阶段学的“把纯计算逻辑和交互逻辑拆成两个独立函数”的思路，和面向对象阶段的类拆分逻辑本质完全一致：只是过程式阶段的纯逻辑是无状态的自由函数，面向对象阶段的纯逻辑是封装了状态（比如这道题的两个操作数、当前运算类型）的类，核心的解耦目标从来没有变过。
• 顺便提你代码里的一个残留bug：getRand()方法里在第一行return之后写的int min = max / 10;是完全执行不到的死代码，而且会遮蔽类的私有成员min，属于拆分逻辑时没清理干净的残留，记得删掉。

内容的提问来源于stack exchange，提问作者Hohlkopf