Java控制台点餐系统设计与总价计算

本文深入探讨了Java控制台点餐系统中几个关键设计决策：通过将价格计算逻辑从菜单项数据中剥离、推迟至订单生成时动态执行，避免了硬编码价格导致的折扣与促销扩展难题；采用每次调用`getTotal()`都实时累加各菜品`getFinalPrice()`的方式，彻底规避了缓存总价引发的状态不同步风险；统一使用`nextLine()`配合`try-catch`解析用户输入，有效防御非法输入导致的程序崩溃；并基于实际业务需求（如频繁增删菜品）坚定选择`ArrayList`而非数组，兼顾安全性与可维护性——这些看似微小的设计取舍，实则直击面向对象开发中松耦合、高内聚、易扩展的核心诉求，让代码不仅跑得稳，更经得起业务演进的反复锤炼。

菜单类怎么设计才不重复算价格

菜单项如果直接用 double 存价格，后续做折扣、满减、套餐拆分就容易出错——因为价格逻辑被写死在数据里了。应该把价格计算推迟到订单生成时，靠方法动态算。

• 菜单项类（MenuItem）只存基础字段：name、basePrice、isVegetarian 等，不存“当前售价”
• 真正要算钱的地方是 Order 类里的 calculateTotal() 方法，它遍历所有 MenuItem 实例并调用各自的 getFinalPrice()
• 如果某道菜有会员价，就在 MenuItem 里加个 getFinalPrice(CustomerType type)，而不是新增一个 memberPrice 字段

订单类如何避免 add() 后总价不更新

常见错误是把总价存在字段 total 里，然后在 add(MenuItem item) 里忘了重算——结果 getTotal() 返回的还是旧值。

• 不要缓存总价；每次调用 getTotal() 都重新遍历 items 列表并累加 item.getFinalPrice()
• 如果真要缓存（比如订单很大），必须确保所有修改订单的操作（add、remove、updateQuantity）都同步更新 total 字段
• 更安全的做法是去掉 total 字段，只留 getTotal() 方法——Java 中函数调用开销几乎可忽略，省去状态同步的麻烦

控制台输入菜品编号时怎么防崩

用户输个 abc 或空行，Scanner.nextInt() 就抛 InputMismatchException，程序直接退出。这不是功能缺陷，是没处理边界输入。

• 别用 nextInt() 直接读编号；先用 nextLine() 读整行，再用 Integer.parseInt() 转，包在 try-catch 里
• 转完检查范围：if (id menuItems.size())，提示“编号不存在，请重试”
• 输入流残留问题：nextInt() 不吞换行符，后面跟 nextLine() 会立刻返回空字符串——统一用 nextLine() + 解析，最稳

为什么用 ArrayList 而不是数组存菜单项

菜单后期大概率要增删（比如下架菜品、临时加新品），用数组就得手动扩容、复制，错一步就 ArrayIndexOutOfBoundsException。

• ArrayList 支持动态增删，add() 和 remove() 安全可靠
• 遍历时别用传统 for 循环配 size()——如果循环中删了元素，索引会错位；改用增强 for 或迭代器
• 不需要随机访问性能优化（比如按 ID 查菜），就别提前建 Map；先跑通逻辑，再看是否真慢

菜单和订单之间的耦合点其实就两个：一是订单依赖菜单项的定价逻辑，二是编号选择需要菜单长度校验。其他地方越松越好——比如订单类完全不知道菜单怎么打印，也不该知道。

以上就是《Java控制台点餐系统设计与总价计算》的详细内容，更多关于的资料请关注golang学习网公众号！