在 Java 面向对象开发中，用户交互提示消息（如“Create how many trains?”）应定义在承载业务逻辑的类内部（如 Train 类的方法中），而非 main() 方法中，以保障高内聚、低耦合、可维护性与可测试性。
在 java 面向对象开发中，用户交互提示消息（如“create how many trains?”）应定义在承载业务逻辑的类内部（如 `train` 类的方法中），而非 `main()` 方法中，以保障高内聚、低耦合、可维护性与可测试性。
将用户提示字符串直接写在 main() 方法中看似简单，但会破坏职责分离原则：main() 仅应负责程序启动与流程编排，而不应承担具体业务的交互文案逻辑。相反，提示消息本质上是业务操作（如 createTrain()）的语义组成部分——它描述了该操作期望的用户输入意图。因此，将其内聚地定义在对应方法内部，是最符合封装原则的做法。
例如：
public class TrainManager {
private Scanner scanner = new Scanner(System.in);
public void createTrain() {
String prompt = "Create how many trains?"; // ✅ 与行为强关联，易于定位和修改
System.out.print(prompt);
int count = scanner.nextInt();
// 执行创建逻辑...
}
public void deleteTrain() {
String prompt = "Enter train ID to delete:"; // ✅ 不同操作对应不同提示，自然隔离
System.out.print(prompt);
String id = scanner.next();
// 执行删除逻辑...
}
}注意事项与进阶建议：
- ✅ 避免硬编码重复：若同一提示在多处使用，可提升为
private static final String常量，置于类顶部，兼顾可读性与复用性； - ⚠️ 国际化考量：项目需支持多语言时，应进一步抽取至
ResourceBundle或Properties文件，通过键名（如"train.create.prompt"）动态加载； - ❌ 禁止跨层泄露：切勿让
TrainManager的提示依赖Main类中的变量或方法——这将导致紧耦合，阻碍单元测试（例如无法在无控制台环境下验证createTrain()行为）； - ? 利于测试：内聚提示使方法更易模拟输入（如使用
System.setIn()或依赖注入Scanner），实现纯逻辑验证。
综上，用户提示不是“界面装饰”，而是业务契约的一部分。将其扎根于对应领域类中，是践行面向对象设计原则的务实选择——既提升代码自解释性，也为未来扩展（如日志记录、输入校验、UI 替换）奠定清晰结构基础。
立即学习“Java免费学习笔记（深入）”；
