Java商品管理系统的核心在于Goods、Inventory、Order类是否真正封装业务语义：Goods需校验价格非负、返回非空名称；Inventory应封装库存状态与审计逻辑；OrderItem须持有商品快照而非仅ID；toString和equals须体现业务关键字段。
Java 商品管理系统的核心不在“系统”二字，而在 Goods、Inventory、Order 这些类是否真正封装了业务语义——不是把字段塞进 class 就算封装，而是让对象能自己回答“库存够不够”“价格含不含税”“这个商品还能上架吗”。
用 private + getter/setter 不等于完成了封装
常见错误是把所有字段设为 private，再配上 IDE 自动生成的 getXXX()/setXXX()，就认为封装完成了。这其实只是“隐藏了字段”，没封装“行为”。比如：
-
setPrice(double price)允许传入负数，但商品价格不能为负 -
setStock(int stock)允许设为 -5，导致后续扣减逻辑崩溃 -
getName()返回null，调用方每次都要判空，违反封装契约
正确做法是在 setter 里做校验，在 getter 里返回不可变视图或默认值：
public class Goods {
private String name;
private double price;
private int stock;
<pre class='brush:java;toolbar:false;'>public void setPrice(double price) {
if (price < 0) throw new IllegalArgumentException("价格不能为负");
this.price = price;
}
public String getName() {
return this.name != null ? this.name : "";
}}
立即学习“Java免费学习笔记（深入）”；
为什么 Inventory 不该只是 Map<String, Integer>
直接用 HashMap<String, Integer> 存商品 ID 和库存量，看似简单，但会快速失控：
- 缺货预警、库存流水、批次管理、冻结库存等逻辑无处安放
- 多线程下
map.get(id) - 1再put是非原子操作，必然丢数据 - 无法统一控制“库存变更必须记录操作人和时间”这类业务规则
应定义 Inventory 类，把库存视为有状态、可审计的实体：
public class Inventory {
private final Map<String, StockItem> items = new ConcurrentHashMap<>();
<pre class='brush:java;toolbar:false;'>public boolean deduct(String goodsId, int quantity) {
return items.computeIfPresent(goodsId, (id, item) ->
item.canDeduct(quantity) ? item.deduct(quantity) : null
) != null;
}
// StockItem 内部封装了可用量、冻结量、历史变更列表等}
立即学习“Java免费学习笔记（深入）”；
Order 对象必须持有 Goods 引用，而非只存 goodsId
很多初学者让 Order 只存 String goodsId，然后在业务层反复查数据库或缓存去取商品信息。这带来三个硬伤：
- 订单快照失效：商品名称/价格改了，历史订单显示新值，失去溯源能力
- 事务边界模糊：下单时价格校验和库存扣减跨多个对象，容易不一致
- 序列化/日志困难：打印一个
Order对象，只看到 ID，看不到实际买了什么
正确方式是让 OrderItem 持有完整 Goods 快照（或不可变副本），并显式记录当时的价格与单位：
public class OrderItem {
private final Goods goods; // 不是 GoodsDao.findById(...)
private final BigDecimal unitPrice; // 下单时刻锁定的价格
private final int quantity;
<pre class='brush:java;toolbar:false;'>public OrderItem(Goods goods, int quantity) {
this.goods = Objects.requireNonNull(goods);
this.unitPrice = BigDecimal.valueOf(goods.getPrice());
this.quantity = quantity;
}}
立即学习“Java免费学习笔记（深入）”；
toString() 和 equals() 不是模板代码，是调试生命线
开发时 70% 的排查时间花在看日志、断点、单元测试输出上。Goods.toString() 如果只返回 Goods@1a2b3c，你就得一层层点开 debug 视图；而一行清晰的字符串能立刻告诉你问题在哪。
同理，equals() 写错会导致 Set<Goods> 去重失败、Map 查不到 key、Mockito 匹配失败——这些错误不会编译报错，但会在运行时静默出错。
建议用 Lombok 的 @Data（注意它默认用所有字段生成 equals，要排除掉 createDate 等非业务字段），或手写时只基于业务主键（如 goodsId）判断相等性：
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Goods goods = (Goods) o;
return Objects.equals(goodsId, goods.goodsId); // 只比 ID
}真正的封装难点从来不在语法，而在于每次加一个字段、改一个方法时，你有没有问一句：“这个改动，会不会让对象违背它原本承诺的行为？”——比如让 isInStock() 在库存为 0 时突然返回 true，就是对封装契约的破坏。
