面向对象设计购物车应明确product、shoppingcart、user、order四类职责：product仅管自身信息；shoppingcart只负责增删改查与总价计算；user持有购物车；order由购物车快照生成且生命周期独立；通过封装、接口抽象（如promotionstrategy）和松耦合关系实现可维护性。
用面向对象设计购物车，核心是把“人”“商品”“购物车”“订单”这些现实概念映射成类，明确各自职责和关系，而不是堆逻辑或用一堆 Map/List 硬凑。
明确核心角色与职责
先想清楚系统里谁在干什么：
- Product（商品）：只管自己信息——ID、名称、单价、库存。不关心卖没卖、加没加购物车。
- ShoppingCart（购物车）：只管“装什么、装几个、能算总价、能增删改”。不负责结账、不操作库存、不生成订单。
- User（用户）：持有购物车（一对一），可能有收货地址、历史订单等，但购物车本身不依赖用户身份。
- Order（订单）：结账时由购物车“快照”生成，包含时间、商品明细、实付金额；生成后购物车清空，两者生命周期分离。
合理建模关键关系
避免强耦合，比如别让 Product 类里写“被加入购物车次数”这种业务统计逻辑：
- 购物车用 Map
存商品和数量——键是商品对象（重写 equals/hashCode 按 ID 判等），值是数量，自然支持同一商品多次添加合并。 - 商品类不持购物车引用，购物车也不改商品库存；库存扣减留到下单时由订单服务统一校验+扣减，职责清晰。
- 用户类中声明 private ShoppingCart cart = new ShoppingCart();，而不是每次 new 或从外部传入，体现“人拥有购物车”的语义。
封装行为，拒绝数据裸奔
别暴露内部集合，用方法控制访问：
- 购物车提供 add(Product p, int quantity)，内部自动合并数量、校验库存（可抛异常或返回布尔）。
- 提供 getTotalPrice() 计算当前所有商品小计，而不是让外面遍历 map 自己算。
- 删除用 remove(Product p) 或 clear()，不暴露 map 的 remove(key) 给调用方。
- 需要查看明细？返回 unmodifiableMap 或封装为 List
（CartItem 是只读包装类），防止外部篡改。
留扩展接口，不硬编码细节
比如促销规则变化快，别把满减逻辑写死在 ShoppingCart 里：
- 定义 PromotionStrategy 接口，含 apply(List
items): BigDecimal 方法。 - 购物车持有一个策略实例（构造注入或 setter 注入），getTotalPrice() 内部调用策略计算优惠后价格。
- 后续加“第二件半价”“会员折扣”，只需新增实现类，购物车代码零修改。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
