为何亚马逊购物系统需将Customer与Account类分离？

这是典型的面向对象设计中单一职责原则和关注点分离的实践，分开这两个类的原因和优势主要体现在以下几个方面：

• 单一职责，避免代码臃肿
  Customer类专注于购物行为相关的核心逻辑（比如购物车的访问与操作），Account类则聚焦于身份认证、个人信息维护（收货地址管理）和账户相关操作（商品评论、收藏/删除商品）。如果合并成一个类，会导致它同时承载两类完全不同的职责，代码量剧增，后续修改某一功能时很容易误触其他无关逻辑，大幅提升bug风险和维护成本。

• 适配多样化的用户场景
  亚马逊的用户群体包含未登录的访客（Guest）：这类用户可以添加商品到购物车，但不需要拥有Account（没有收货地址、评论权限等账户相关功能）。拆分设计后，访客可以直接实现Customer抽象类，无需被迫继承或包含Account的冗余功能。反过来，管理员这类角色只需要Account来管理身份和权限，完全不需要购物车功能，拆分能让角色职责更精准，避免不必要的功能耦合。

• 提升扩展性与复用性
  如果后续要扩展业务场景，比如新增「企业采购用户」这类角色，他们的购物逻辑可能和普通个人用户不同，但身份信息管理逻辑可以复用现有Account类。这时只需要扩展Customer的子类即可，无需改动Account的代码。同理，要是升级Account的地址管理功能（比如支持多地址默认设置），也完全不会影响Customer的购物车逻辑，两个模块可以独立演进，符合开闭原则。

• 清晰的业务边界与逻辑分层
  从业务本质来看，「购物行为主体」和「身份账户」是两个独立的概念：用户的账户是长期存在的身份标识，而购物车是临时的会话级行为载体。拆分后代码结构更贴合真实业务流程，后续维护时能快速定位到对应模块，降低团队成员的理解和协作成本。

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