想要和我们的技术团队进行一次免费的沟通?

当然可以！
我们会直击要点，回答你的所有疑问，并介绍我们的服务。
还有顾虑？
我们可以提供免费的面试实战展示。我们团队到底有多少水平，你说了算。

近期最常见的OOD题目

第二轮面试中，看到 “Pizza Price Calculator” 的第一眼，我就知道这不是算法题，而是一道考察代码设计和可扩展性的经典面试题。题目看起来很直白：不同的 pizza base、不同的 topping 各自有价格，不同 size 对应一个倍率系数，比如 crust base 是 3 美元、cheese topping 是 2 美元、medium size 要乘以 1.5 倍，最终价格公式是 (base + toppings) × multiplier。顾客下单时必须指定 size、选择一个 base，并可添加 0 个或多个 topping。光从功能角度实现一个计算器非常容易，但要写出一份能在面试中拿高分的代码，就得体现出我对对象建模、扩展性和设计模式的理解。

设计思路：分离结构与逻辑

我首先想到的，是不能让 Pizza 类同时负责存储属性和计算价格。那样虽然短期内可行，但职责太重，后续如果要加入折扣、会员价、节日优惠，就得改核心类逻辑，这显然违反开闭原则。更好的方式是让 Pizza 类只承担“描述性”的角色，它只表示这个 pizza 有什么 base、多大尺寸、包含哪些 toppings，而不直接计算价格。价格计算应该交给一个独立的模块，比如一个价格计算器（PriceCalculator）。这样一来，Pizza 类不会关心价格规则，而 PriceCalculator 可以灵活扩展。比如我可以创建一个基础计算器、一个带优惠的计算器、一个促销计算器，它们都基于同一接口实现不同逻辑，而不需要修改核心结构。这种“逻辑与数据分离”的设计体现了 策略模式（Strategy Pattern） 的思想，也是很多面试官非常看重的架构意识。

扩展思考：当订单包含多种商品

在 follow-up 阶段，题目会进一步要求支持顾客下多个订单，并且订单中可能包含 pizza、饮料（drink）、甜点（dessert）等不同类型的商品。这时如果系统仍然只围绕 pizza 设计，就会非常僵化。于是我换了个角度去看：pizza、drink、dessert 本质上都是“可以计算价格的商品”。既然如此，那我就不该让系统依赖某个具体商品，而该抽象出一个更通用的概念——订单项（OrderItem）。所有商品都可以实现同样的接口，比如都有 getPrice() 的行为。这样，订单（Order）只需聚合若干个 OrderItem，然后计算总价即可。它不关心每个商品的内部细节，只要知道它们都能自己报出价格就行。这种结构正是 组合模式（Composite Pattern） 的体现：每个订单项既可以是独立对象，也可以是组合结构。未来要扩展新的商品类别，只需新增类实现相同接口，原有系统完全不用改。

从能跑到能演化

回过头看这道题，我觉得它是一道非常典型的“表面简单、实则见功力”的题。能写出能跑的代码只是基础，而能写出结构清晰、易扩展的设计才是关键。面试时如果我直接讲出“我通过策略模式解耦了价格逻辑，用组合模式抽象了订单结构”，面试官会立刻意识到我在思考系统的演化性，而不是在堆砌逻辑。这种回答自然、逻辑清晰，也展示出我对 面向对象设计原则（尤其是开闭原则和单一职责）的真正理解。