account类应封装状态变更规则：balance设为private，仅提供getbalance()读取；存款、取款、转账均通过方法实现，且各方法内部校验合法性（如余额非负、账户有效等）。
Account 类怎么设计才符合银行账户的业务逻辑
银行账户不是普通数据容器，必须封装状态变更规则。比如余额不能为负、转账需校验双方账户有效性、操作要带时间戳。直接用 public double balance 是危险的——外部可随意修改，失去控制权。
实操建议：
- 把
balance设为private，只提供getBalance()读取，不暴露 setter - 所有写操作通过方法实现：
deposit(double amount)、withdraw(double amount)、transferTo(Account target, double amount) - 每个方法内部做合法性检查：
if (amount - 建议在构造时强制传入初始余额和账号（
String accountNumber），避免空对象
为什么 withdraw() 方法里要用 if-else 而不是直接减法
因为银行系统必须拒绝非法取款，而不是让余额变负数再抛异常。很多初学者写成 balance -= amount 后判断是否为负，这已造成状态污染——错误发生后余额已被错误修改，回滚困难。
正确做法是先验证，再变更：
立即学习“Java免费学习笔记（深入）”；
public boolean withdraw(double amount) {
if (amount <= 0 || amount > balance) {
return false; // 拒绝操作，不改状态
}
balance -= amount;
return true;
}
这样调用方能明确知道操作是否成功，也便于后续扩展日志或事件通知。
转账操作为什么不能只靠两个 Account 对象互相调用
看似简单：A 调 withdraw()，B 调 deposit()。但这是两步独立操作，中间若发生异常（如网络中断、JVM 崩溃），就会出现“A 扣了钱、B 没到账”的资金丢失问题。
简易系统可用同步事务思维规避：
- 转账方法必须定义在第三方服务类（如
BankService）中，而非任一 Account 内部 - 先校验 A 余额充足、B 账户存在，再执行 A 扣款、B 入账——两步都在同一方法内完成
- 如果 B 入账失败（比如目标账户被冻结），立刻对 A 执行补偿性
deposit(amount)，并返回失败 - 注意：这里没有数据库事务，所以补偿逻辑必须幂等，例如检查 A 当前余额是否已扣减，避免重复返还
main 方法里测试时容易忽略的边界情况
新手常只测“正常存 100、取 50”，但银行系统最怕边界值出错。以下几类必须覆盖：
-
deposit(-10.0)→ 应抛异常或返回 false -
withdraw(0)和withdraw(Double.MAX_VALUE)→ 防止溢出或逻辑绕过 - 两个账户互相转账（A→B，紧接着 B→A）→ 检查是否因锁顺序引发死锁（单线程无感，多线程会卡住）
- 用
double存金额 → 实际项目中应改用BigDecimal，否则 0.1 + 0.2 ≠ 0.3，会产生分币级误差
真正上线的账户系统不会用 double，但教学演示常忽略这点，导致后期迁移到 BigDecimal 时逻辑重写成本很高。
