C++类中为何不建议使用输入输出？是否属于行业标准？

Hey there! Great question—this is a common point of confusion for folks diving into C++ class design, so let’s break it down clearly.

This isn’t just one speaker’s take—it’s a widely accepted best practice rooted in object-oriented design principles and software engineering fundamentals. Most seasoned C++ developers and style guides (like the C++ Core Guidelines) advocate for keeping I/O operations out of business logic classes.

Let’s break down the key reasons:

• Violates the Single Responsibility Principle: A class should have one, and only one, reason to change. For example, a BankAccount class should handle account logic (deposits, withdrawals, balance checks)—not worry about printing to the console or writing to a log file. If you hardcode cout into the class, you’ll have to modify it later if you want to switch to logging to a file, or disable output entirely in a headless environment. That’s a violation of the Open/Closed Principle too (classes should be open for extension, closed for modification).
• Kills reusability: A class with hardcoded I/O is tied to a specific output medium. You can’t reuse that class in an embedded system with no console, or a backend service that logs to a database instead of stdout. By separating I/O from business logic, your class becomes portable across different environments.
• Makes testing harder: If your class spits out cout messages, unit testing becomes a hassle. You can’t easily assert that the right output was generated without jumping through hoops to capture stdout. On the other hand, using exceptions to signal errors lets you write clean tests that catch specific exceptions and validate error conditions programmatically.
• Breaks encapsulation: Internal I/O exposes implementation details to users. Someone might start relying on the exact format of your cout output, which means you can’t change that output later without breaking their code. Classes should communicate via their public interface (methods, return values, exceptions)—not through side effects like console output.

Using exceptions to signal error conditions instead of printing error messages directly in the class is absolutely standard practice. But let’s clarify:

• Exceptions are for unexpected errors, not for normal status updates. You wouldn’t throw an exception to say "Deposit successful"—but you would throw an exception like InsufficientFundsException if someone tries to withdraw more than their balance.
• Normal informational output should be handled by the code that uses your class, not the class itself. Your class should return data or state, and the caller decides whether to print it, log it, or display it in a GUI.
• The advantage of exceptions over cout for errors is that they’re structured and actionable. A caller can catch the exception, log it appropriately, and handle the error gracefully—whereas a cout message is just text that humans have to read, with no easy way for code to respond to it.

It’s not a hard ban! Classes whose entire purpose is handling I/O (like a FileLogger, ConsolePrinter, or NetworkStreamWriter) should absolutely include I/O logic. The rule applies to business logic classes—ones that exist to model data or perform operations unrelated to input/output.

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