OOD 面试方法论：45 分钟的节奏

这一轮到底在考什么

低层设计（LLD），也常叫 OOD（Object-Oriented Design）面试，题目通常是“设计一个停车场”“设计一个 LRU 缓存”“设计电梯系统”。它和高层系统设计（HLD）的关注点完全不同：

面试官想看到的不是你背过多少设计模式，而是三件事：能不能把模糊需求收敛成清晰模型、类的职责划分是否合理、核心逻辑能不能写对。不少北美公司都有这类轮次，有的要求在共享编辑器里写出能编译的代码，有的只要类图加伪代码——开场时直接问清楚，别自己猜。

五步走

flowchart LR
  accTitle: OOD 面试的五步与时间分配
  s1["澄清需求（5-8 分钟）"] --> s2["识别实体（5 分钟）"] --> s3["定义关系与接口（8-10 分钟）"] --> s4["写核心代码（15-20 分钟）"] --> s5["扩展与权衡（5 分钟）"]

1. 澄清需求（别跳过）

先列出 3-5 个功能需求和 1-2 个非功能需求，写在编辑器顶部，让面试官确认。以停车场为例：

• 支持哪些车型？车位是否分尺寸？
• 多入口多出口吗？需要并发安全吗？
• 怎么计费？需要完整的支付流程吗？（通常回答：支付抽象成外部接口）

关键是主动收缩范围：“支付和会员系统我先当作外部接口，重点放在车位分配和计费上，可以吗？”这句话本身就是加分项，说明你知道 45 分钟能做什么、不能做什么。

2. 识别核心实体

名词找类，动词找方法。把题目描述读一遍，圈出名词：

“车辆从入口进入，系统分配车位并发放停车票，
  车辆离开时在出口按时长计费。”
名词: 车辆 入口 车位 停车票 出口 → Vehicle, Gate, Spot, Ticket
动词: 分配 发放 计费           → allocate(), issueTicket(), fee()

不是每个名词都值得成为类。“时长”只是 Ticket 上入场时间和离场时间的差，不需要单独建类。判断标准：它有没有自己的状态或行为？没有就只是一个字段或一个计算结果。

3. 定义关系与接口

用简单的文字类图即可，不需要标准 UML 符号：

ParkingLot 1──* Level 1──* Spot
Spot ──> Vehicle (0..1)
Ticket ──> Spot, Vehicle
PricingStrategy <── HourlyPricing

这一步要想清楚：哪些是稳定的（实体本身），哪些是会变的（计费规则、分配策略）。会变的部分放到接口后面，这就是后面 SOLID 章节里开闭原则在面试中的真实落点。不会变的部分直接写具体类。

4. 写核心代码

不要把所有 getter/setter 都写出来，那是在浪费时间。挑最难、最能体现设计的那条路径：停车场是 park() 和 unpark()；LRU 是 get() 和 put()；电梯是调度逻辑。用 enum 表示状态和类型，方法名要明确，边写边说你在做什么、为什么。

5. 扩展与权衡

留几分钟主动讲：

• 并发：多个入口同时分配同一车位怎么办？
• 扩展：加电动车充电位、加预约功能，需要改哪几个类？
• 取舍：为什么这里用组合而不用继承？为什么这里用一把全局锁就够了？

面试官往往会顺着你抛出的点追问，所以主动讲等于在引导面试走向你准备好的方向。

常见失分点

1. 上来就写代码：没澄清需求，写到一半发现方向错了，时间已经不够重来。
2. 上帝类：一个 ParkingLotManager 包揽分配、计费、打印、持久化。
3. 过度设计：每个类都配接口加工厂，只有一种实现的接口纯属噪音。
4. 只画图不写码：类图很漂亮，核心方法一行没写对。
5. 沉默：长时间不说话。LLD 面试很看重思考过程，沉默等于不给分。

英文表达模板

对母语非英语的同学，提前准备几句话能省很多紧张：

• “Before I start, let me clarify a few requirements.”
• “I'll treat payment as an external service to keep the scope manageable.”
• “This part is likely to change, so I'll put it behind an interface.”
• “Let me walk through the main flow end to end.”
• “One trade-off here is...”

记住：LLD 面试是一场对话，不是闭卷考试。让面试官看到你如何做决定，比给出所谓的“标准答案”重要得多。