面向对象购物车结算强调职责分离：product只管自身属性且不可变；cartitem封装商品与数量并计算小计，重写equals/hashcode以合并同商品；shoppingcart用map管理项并委托discountstrategy处理折扣；结算由独立orderservice触发，确保各模块低耦合、高内聚。
面向对象思想在购物车结算中不是把“算钱”写成一个方法就完事，而是让每个角色各司其职、彼此协作，结算逻辑自然浮现出来。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
商品不负责算账，只管“我是谁、值多少、还剩几个”
Product 类应保持简单干净：id、name、price、stock 全用 private + final（或至少只提供 get 方法），不暴露修改库存或价格的入口。它不关心自己被加到哪个购物车、买了几件——这些是别人的事。结算时需要它的 price 和 stock，就通过 get 方法拿，不越权、不耦合。
购物车项（CartItem）封装“某商品买了几件”这个事实
CartItem 不是 Product 的复制体，而是持有对 Product 的引用，并记录 quantity。它自己提供小计计算：
public BigDecimal getSubtotal() { return product.getPrice().multiply(BigDecimal.valueOf(quantity)); }
关键点在于：重写 equals 和 hashCode，以 product.id 为唯一依据。这样添加同一商品两次时，购物车才能识别“这是同一个东西”，自动合并数量，而不是堆两条重复记录。
购物车（ShoppingCart）专注管理，不掺和折扣规则
ShoppingCart 是个容器，用 Map
它计算总价时只做一件事：遍历所有 CartItem，累加 getSubtotal()。
折扣逻辑不写死在里面。而是留个接口：
public BigDecimal getFinalAmount(DiscountStrategy strategy)
真正打折怎么算，交给 strategy 去决定。VIP 打八折、满 300 减 50、新用户首单立减——换策略就行，购物车类完全不用动。
结算动作由独立流程触发，不是购物车的“义务”
结算（checkout）通常是一个独立行为，可能属于 OrderService 或 CheckoutProcessor 类。
它从 ShoppingCart 拿出全部 CartItem，检查库存是否足够（调用 product.reduceStock(quantity)），生成 Order 对象，预扣库存，再调用支付网关。
购物车本身不生成订单、不调支付、不发短信——职责分明，改一个功能不影响另一个。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
