在Java里如何实现简易ATM模拟程序_Java对象与集合实践说明

ATM核心实体应建模为Account（管余额与存取款校验）、Transaction（不可变交易记录）、ATM（持账户Map与交易LinkedList）；账户用HashMap按卡号索引，交易用LinkedList追加，金额用double或BigDecimal避免精度问题。

如何用Java类建模ATM核心实体（Account、ATM、Transaction）

ATM模拟的关键不是界面或IO，而是把“账户”“取款动作”“余额变动”这些现实概念映射成可协作的Java对象。别一上来就写Scanner读输入，先定义清楚职责边界：

• Account只管自己的balance、accountNumber，提供withdraw(double amount)和deposit(double amount)，且必须校验金额非负、取款不超余额
• Transaction是不可变记录：含type（"WITHDRAW"/"DEPOSIT"）、amount、timestamp（用System.currentTimeMillis()即可）
• ATM类不存余额，只持有一个List和一个List，所有业务逻辑通过调用Account方法完成

这样设计后，测试单个账户逻辑时完全不需要启动ATM——直接new一个Account调withdraw()就行。

用ArrayList还是HashMap管理多个账户？

用户登录靠卡号（字符串），查账户是高频操作。用ArrayList遍历查找，时间复杂度O(n)；而HashMap按accountNumber做key，get操作平均O(1)。实际中后者更合理：

private Map accounts = new HashMap<>();
// 添加账户
accounts.put("6228480000000000000", new Account("6228480000000000000", 5000.0));
// 根据卡号快速获取
Account acc = accounts.get("6228480000000000000");

注意：HashMap的key必须是不可变对象，String符合；如果自己写Account类作为key，就得重写hashCode()和equals()——但这里没必要，卡号字符串已足够唯一。

立即学习“Java免费学习笔记（深入）”；

Copy Leaks

AI内容检测和分级，帮助创建和保护原创内容

下载

为什么Transaction列表要用LinkedList而不是ArrayList？

交易记录只追加、不修改、极少随机访问（比如查第5笔），但可能频繁在末尾添加。虽然ArrayList尾部add也是O(1)均摊，但扩容时有数组复制开销；LinkedList每次add都是纯粹指针操作，无扩容成本。更重要的是语义清晰：LinkedList明确表示“这是一个按时间顺序追加的线性日志”。不过若后续要支持“查最近10笔”，用ArrayDeque会更省内存，但对简易ATM，LinkedList足够直观。

• 别用ArrayList存交易然后每次add(0, tx)倒序插入——那是O(n)操作，严重拖慢
• 交易列表不应暴露给外部修改，声明为private final List transactions = new LinkedList();，只提供addTransaction(Transaction tx)方法

常见运行时错误及规避方式

真实跑起来最容易崩在三处：

• NullPointerException：用户输错卡号，accounts.get("xxx")返回null，接着调acc.withdraw(100)就炸。必须检查acc == null并提示“卡号不存在”
• InputMismatchException：用Scanner.nextDouble()读取金额时，用户输了个"abc"。应在try-catch里捕获，并scanner.next()清掉非法输入，否则下次读取仍失败
• 余额透支：取款前没校验if (amount > acc.getBalance())，导致余额变负数。这是业务逻辑漏洞，不是异常，必须在Account.withdraw()内部拦截并抛IllegalArgumentException

所有金额运算避免用float——精度丢失会导致0.1+0.2≠0.3。一律用double（教学场景可接受）或BigDecimal（生产级必需），但后者构造必须用字符串：new BigDecimal("100.50")，不能用new BigDecimal(100.50)。