当了5年亚马逊面试官，我总结了5步【面向对象设计】套路
作者：文泰来
九章算法《面向对象设计OOD》金牌讲师
Amazon资深工程师，多年面试官经验，曾斩获Google, Facebook, Uber等多家公司offer
大家应该都知道今年疫情关系，大量科技公司在裁员、缩招，而我供职的Amazon是为数不多一直在招的，而且这次一放就是2万技术岗。
几乎每周我都要参与面试（现在是VO），主要负责设计面试，所以知道很多候选人遇到的问题都是一样的。趁着WFH，我将大家最常见的问题整理出来，同时我会用具体例题解释如何评判一轮设计面试是好的。
OOD和系统设计到底区别在哪里？
在多年从事教学的过程中，同学们往往一上来就问：老师，OOD和系统设计的区别在哪里？
在这里我先用一张图简单标明两者在面试里的区别：
需要特别强调：这5个方面的比较，并不是你处于哪个位置就一定会遇到OOD或系统设计，只是从统计学角度出发，当你在这个条件当中，被考到的概率更大。
今年就业情况非常差，包括亚麻在内的公司的面试难度都提高了，很多岗位考完一轮OOD，还有一轮系统设计。
可以说除算法外，OOD必考！面试官通常以此来判断一个程序员的基础和大局观。
特别强调：我今年就面过好几个4~5级的同学，算法答得很好，但设计亮了红灯，我们review以后都直接挂掉了！
菜鸟到高手，OOD解题套路5步走
既然OOD这么重要，那问题来了：如何评判一轮OOD面试？评判标准是什么？
很多同学问：我知道面算法时，可以通过时间复杂度或空间复杂度来判断做的好不好。但设计题我画了一整块白板，也说了很多很多，面出来却还是懵逼的！
因为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是什么样的，欢迎大家来听我的在线分享，我会更详细给大家展示。
怎么听在线分享？
长按扫码 - 跳转后点击免费试听即可, 或点击《面向对象设计OOD》
第三步：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，大家不妨去听我的免费分享课，其中我会讲到具体的代码实现：
免费分享课怎么听？
长按扫码，点击免费试听即可，或点击《面向对象设计OOD》
