当了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免费试公开课里提到的一个核心点,我先将类图分享出来:

image

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

可能讲到这里,有些同学还没完全理解Strategy Pattern,大家不妨去听我的免费分享课,其中我会讲到具体的代码实现:

免费分享课怎么听?

长按扫码,点击免费试听即可,或点击《面向对象设计OOD

展开阅读全文

没有更多推荐了,返回首页

应支付0元
点击重新获取
扫码支付

支付成功即可阅读