大决战·微软面经（七）：第二面，战胜“设计模式”

Posted by realdodo

十二月 1, 2006

像走迷宫一样，我随着面试官来到不同于刚才的另一个房间。

他给我的第一感觉是，瘦，第二感觉是，说话快。

又是全英语面试，没有任何选择。一开始很有些不习惯，说英语真的很快，有些跟不上，但是很快就适应过来了，毕竟都是中国人，互相之间在怎么样也挺容易理解。他看了看我的简历，马上就开始针对简历的内容提问。

“看你简历上写熟悉设计模式，在那么多项目之中，哪个项目设计最为复杂？”他问道。我选择今年上半年做的ASN.1编译器项目，并简单说了项目的工作内容以及用到的一些技术。

接着，他就出了一个听起来挺复杂的需求要我设计一个类体系，希望我尽量用一些面向对象的设计方法来解决问题。我简单思考了一下，画了一个协作图的草图。不过马上就觉得不爽，又画了一个第二版。在这个图里面我没有写任何的接口，所有的关系都依赖于实际的功能类，我是故意这样做的。我知道他接下来的问题肯定针对这种设计的扩展性展开，所以我等着在问题中提出想法。

果然，他问我为什么要把一些功能分出来，目的和意义是什么。我就说，如果这个类抽象出一个接口的话，那我就能支持新的功能，而且使得整体结构不变，顺手，我改掉了协作图的关系，加上新的内容。然后又是类似的问题，我慢慢为这个框架加入新的接口，引入更多的间接层次，慢慢的，设计模式也就跟着冒出来了——这就是重构的思想了，只在必要的时候引入设计模式！

协作图看来让他非常的满意，接着就是实现核心代码了。这一点让我郁闷了一两分钟，毕竟，这个需求有点大，从哪里开始下手比较好呢？他看我发了一会呆，就好心的提醒我要把握时间，不要等到时间到了什么东西都没写那就不好评价了。OK，我马上开始下笔如飞的写代码，恰好此时我也找到了写代码的门路。

由于肯定无法写完所有的代码，而且类的层次已经确定，所以我发现只要关注核心业务逻辑就可以。也就是说，所有的真正功能用函数调用和功能类来表示，于是，写代码就类似于写伪码，临时创造一些必要的功能类都可以。我一共写了三个成员函数，提交上去之后感觉不错，他似乎也非常满意。看来这一次我差不多过关了。

“好的，我们再回到你的简历吧，设计的问题就到这里。”他结束了设计与编程的考察，我心里暗暗的松了口气。