当了 5 年亚马逊面试官，我总结了 5 步 [面向对象设计] 套路

大家应该都知道今年疫情关系，大量科技公司在裁员、缩招，而我供职的 Amazon 是为数不多一直在招的，而且这次一放就是 2 万技术岗。

几乎每周我都要参与面试（现在是 VO ），主要负责设计面试，所以知道很多候选人遇到的问题都是一样的。趁着 WFH，我将大家最常见的问题整理出来，同时我会用具体例题解释如何评判一轮设计面试是好的。

很多同学问：我知道面算法时，可以通过时间复杂度或空间复杂度来判断做的好不好。但设计题我画了一整块白板，也说了很多很多，面出来却还是懵逼的！

因为 OOD 面试覆盖面大，又没有标准答案，大家很容易有懵逼的感觉。设计类面试的要领在于沟通清楚再下手，比你一上来就做个大而全的东西更加分，这里就要用到 5C 解题法。

什么是 5C 解题法？

• Clarify：通过和面试官交流，去除题目中歧义，确定答题范围
• Core objects：确定题目所涉及的类，以及类之间的映射关系
• Cases：确定题目中所需要实现的场景和功能
• Classes：通过类图的方式，具体填充题目中设计的类
• Correctness：检查自己的设计，是否满足关键点

结合一道真题感受感受：

“ Can you design an elevator system for this building ？”

这是一道非常经典的设计电梯问题，很多人都会觉得这题我会，稳了稳了！马上开搞！

第一步：Clarify 明确需求

我：这部电梯可承载的人数和重量是多少？装在多高的楼里？

面试官：13 人，最大 1050kg 。20 层。

但知道的这些通用属性的数字以后，对你的设计结果帮助是什么呢？无论这部电梯可承载 3 人还是 13 人，一共是 20 层还是 40 层，其实对设计影响并不大。

换个思路，你可以问面试官：

• 需不需要考虑超载问题？

• 是否需要设计两种类（客梯 or 货梯）？如果需要，他们之间是什么关系？

• 客梯和货梯能到达的楼层是否不一样？

• 这栋楼里当有人按电梯钮时，有多少电梯能响应？

• 当电梯运行时，哪些按钮可以响应？

……

这些都是电梯系统里常见的小问题，却往往被大部分人忽略。现在，有人是不是更迷惑了？方向太多了，怎么能想到所有情况呢？

别慌！面试官的考察点在于你有没有线条清晰的思路，你们之间的沟通是不是正向的，而不是要你想出所有可能的情况。

第二步：Core Objects 核心对象

当碰到 OOD 题目时，可以先在白板上写你的设计一定会有的类。这道题就先把 ElevatorSystem 放上，然后做线性思考，什么东西进来，什么东西出去？

• 有人发请求给我的电梯系统，所以写上 Request ；

• 针对不同的请求，我还要调度一台电梯来响应，所以再写上 Elevator ；

• 电梯里还会有楼层按钮、火警按钮等等，所以需要把 ElevatorButton 加上

接下来就要看这些类之间的映射关系了，大家看图就懂了，ElevatorButton 和 Elevator 之间有一个映射关系，所以我们得分别把很多台电梯，以及很多电梯按钮画在下面。

前两个步骤完成之后，你的白板应该长这样：

Core Objects 这步的作用是：

• 帮助后续的设计明确你需要哪些类；

• 它能承上启下，来自于 clarify 的结果，又成为 use case 的依据；

• 同时还为画类图打下基础

想更深入了解面试时的Good Practice是什么样的，欢迎大家来听我的在线分享，我会更详细给大家展示。

怎么听在线分享？

戳我报名或长按扫码 - 跳转后点击免费试听即可

第三步：Cases 确定场景和功能

Cases 是你和面试官白纸黑字达成的第二份共识，把你要实现的功能列出来；同时也能帮你理清思路，实现一个一个 Case ；最后再作为检查的标准。

每个 use case 只需用一句话描述就行了，篇幅考虑，我直接放图：

第四步：Classes 填充具体的类

OOD 面试很重要的部分就是画类图，为什么？你得明白实际面试场景里，类图的作用：

• 首先类图是最小可交付的结果

• 节约面试时间，不容易在 coding 上挣扎

• 同时它建立在 use case 基础上，条理清晰，便于交流和修改

• 最后若时间允许，便于转化成 code

这里你需要清楚面试官的想法，通常面试官是不会因为只画图不写代码，而对你产生任何偏见的。别慌！

Tips：所以说电面中遇到 OOD 的概率是非常低的，因为经常需要有个白板去和面试官讨论和修改。

第五步：Correctness 检查设计的关键点

“

follow up：针对这个电梯系统，如果我要在人流高峰和低谷期分别有不同的算法，该怎么设计？

”

我直接跟大家演示两种做法：

[方式 1 ] if - else

这里我们处理了高峰期和低谷期（ Normal 的情况），但这种处理方法并不是最优，假如将来我的规则变成：工作日是一种运转系统，周末是另一种运转系统，同时又能结合高峰、低谷的条件，这种方法就需要很大修改。

[方式 2 ] Strategy Design Pattern

这也是我在 OOD 免费试公开课里提到的一个核心点，我先将类图分享出来：

这个类图的优点是：它封装了多种算法、策略，使得算法 /策略之间能够相互替换。既可以被其他人很好地阅读和理解，将来也方便修改或重复使用。

可能讲到这里，有些同学还没完全理解 Strategy Pattern，大家不妨去听我的免费分享课，其中我会讲到具体的代码实现： https://www.jiuzhang.com/course/40/?utm_source=sc-v2ex-fks