面向对象设计：如何正确调用对象内成员对象的方法

核心误解澄清 #

你对官方方案的偏差来自于对getter方法行为的默认假设：getter返回成员对象的副本不是面向对象实现的强制规则。

• 对于Java、Python、C#等主流OOP语言，对象类型默认以引用形式传递，只要getShoppingCart()方法直接返回内部的ShoppingCart成员变量，拿到的就是绑定在当前Customer身上的真实购物车实例引用，此时链式调用customer.getShoppingCart().addItem()的修改会直接作用在原购物车对象上，完全不会出现商品无法存入的问题。
• 对于C++这类默认值传递的语言，只需要将getter的返回值声明为引用类型即可，比如写为ShoppingCart& getShoppingCart() { return shoppingCart; }，同样可以拿到原实例，不会生成独立副本。

常规Java实现参考，完全匹配官方方案的调用逻辑：

public class Customer {
  // 作为成员字段持有的真实购物车实例
  private final ShoppingCart shoppingCart = new ShoppingCart();

  // 返回实例引用，而非副本
  public ShoppingCart getShoppingCart() {
    return this.shoppingCart;
  }
}

// 业务调用：修改直接生效
customer.getShoppingCart().addItem(sku, 2);

关于继承方案的问题 #

你提到的Customer继承ShoppingCart的方案不是“违反直觉”，而是完全不符合面向对象设计原则：

• 继承代表的是is-a关系，用户（Customer）显然不是购物车（ShoppingCart），无法满足里氏替换原则——你不可能在需要购物车实例的业务场景（比如结算、优惠计算）传入一个用户对象。
• 这种写法耦合度极高，后续如果要扩展游客临时购物车、用户多购物车（收藏夹购物车、常购清单购物车）、购物车数据持久化等逻辑，继承结构会完全无法适配。

正确的委托实现方式 #

有两种行业通用的合理实现，都远优于继承方案：

1. 官方方案的引用返回模式
   只要保证getter返回内部购物车的引用而非值副本，链式调用的逻辑就完全成立，优点是代码简洁，不需要写重复的委托方法，适合内部业务逻辑简单、不需要对购物车操作做额外拦截的场景。
2. 薄封装委托模式（更推荐复杂业务场景使用）
   不对外暴露完整的ShoppingCart实例，而是在Customer类中定义细粒度的购物车操作方法，内部直接转调持有的ShoppingCart成员的对应方法。这种写法符合迪米特法则，你可以在委托逻辑中插入用户状态校验、操作日志埋点、商品权限判断等横切逻辑，也不会破坏封装性。

   public class Customer {
     private final ShoppingCart shoppingCart = new ShoppingCart();
     
     // 对外暴露的委托方法，外部不需要感知ShoppingCart的存在
     public void addCartItem(Item item, int quantity) {
       // 可以插入前置校验：比如用户是否被封禁、商品是否可售
       this.shoppingCart.addItem(item, quantity);
     }
   
     public void removeCartItem(Item item) {
       this.shoppingCart.removeItem(item);
     }
   
     public List<CartItem> getCartItemList() {
       // 可以返回不可变副本，避免外部随意修改内部购物车数据
       return Collections.unmodifiableList(this.shoppingCart.getItemList());
     }
   }
   

内容的提问来源于stack exchange，提问作者Guolun Li