为什么面向对象分析与设计的能力这么不受重视

路过。。。算法不好的同样很烦躁。。。但是基本的东西还是要懂的。。。排序、查找、二叉树、队列等等。。。其他高级的Google呗。。。

个人觉得吧，应届毕业生碰到面试设计模式，面向对象分析的公司还是敬而远之吧，面试算法的公司要靠谱多了。

几年前我也认真看过设计模式、面向对象分析的经典书籍，也理解了，然后很确定地以为自己懂了。 等这几年实际项目经验多起来以后，我发现自己那时候的想法就是一坨狗屎。

有些东西想要真正理解注定是离不开大量实践的，时间与经验的积累是必须地。 所以，我要是招初中级职位也不会问这些垃圾东西，找工作碰到满嘴这些东西的公司也会闪的远远的。

纯属个人想法，说不定明天就被我自己否定了，面向对象、设计模式爱好者莫受刺激。

我blahblahblah了一大推，突然想起有一篇文章已经说过这个问题了，果断删掉自己写的。

《为什么我反对纯算法面试题》 酷壳网 陈皓
http://coolshell.cn/articles/8138.html

因为面试你的人自己也不懂啊

算法问题嘛算是比较小规模的考校解决问题的能力的方式，面向对象神马的绝对是异端，对这套异端学说走火入魔的人是很难理解 node.js啊，erlang啊之类新鲜玩意儿的。
不过简单粗暴的就叫你写一个啥排序什么的也是不对地，应该因地制宜的设计一些小品题目，比如解析个神马自定义协议之类的，一个是可以考究一下是不是语文白痴（比如读不懂题，但是首先你得保证你出的题正常人类能够理解，或者你所需要的那个方向的不正常人类能够理解）；第二是考验解决问题的能力（分解，归纳，找到合适的算法）；第三是可以看看写代码的能力，编码习惯什么的；一般看到简历里说对啥语言最熟就要求用啥语言写（如果公司里找不出一个懂的，要么就是此公会的东西太生僻，要么叫他换个主流点的语言写，要么就是此公过于高端，用不起）。出完题最好全公司所有能写代码的都做一遍试试，如果大家在有限时间内都觉得有点难度但是还是能做出来，那么这套题就不错了。最好有时间的时候出个几十道存着，防止有人在网上share。最好每年换一次题

@cranej 受刺激倒不至于
我知道这个东西离不开大量实践，时间与经验的积累，但是他在现阶段却可以让我看懂更多代码的设计意图，我是学linux开发的，linux内核里有太多的设计模式的应用了，我如果没有学过设计模式，我不可能这么快的理解他在干什么，
个人觉得并不应该直接说这是垃圾东西，因为就算在现阶段他不能让我写出好的程序，但它可以更好地让我理解别人的程序

@reus 他懂不懂我就不知道了，不过那个排序太伤人了。。。

@ipconfiger 你说的那个 解析个神马自定义协议之类的，我倒是会，之前写过简单的网络聊天软件和网络五子棋软件，都是自己设计协议，加密，解析什么的，但他就一个排序算法就说我基础差。。。

前东家面试，不要你写什么排序之类的背出来就可以的算法，而是给你一个实际问题，你自己写伪代码说明自己思路。后来机试也是三道实际问题，让你写代码。这些实际问题都是从公司产品中抽取出来的。十几个人比谁写得快写得好，写好了就会被面试官叫到小房间简短面试，问你曾经做过什么最得意的作品，这期间遇到过什么比较难解决的问题，最后是怎么解决的，最后问了未来三五年规划。
这是我记忆最深的一次面试，因为整个面试从笔试、机试、面试走下来都很轻松，聊得很愉快。

@wog 这个嘛，遇到这样子的公司不去也罢，就算去了你也会在工作中遇到明明自己努力了功劳却归了别人的事情。双向选择嘛

被快排秒过一次... 不过说我基础差的话还是服气的，对方气场明显比自己强一个量级

曾以为会用haskell写就没甚在意，被秒杀回来之后用C一写居然用了两个小时(

面试官水平不够呗

说实话，我不喜欢言必谈设计模式的人。

没面试过……

面向对象真的那么重要吗？那没对象的程序员怎么活啊？

这是基本。

不过应该考察得更全面。

想想也好，其实是你筛掉了他们

我是来放地图炮的

很多公司负责招聘的人 and/or 招聘的流程是不讲逻辑的。不讲逻辑的人怎么能让他去写程序，不讲逻辑的招聘流程怎么能筛选出合适的程序员？可是他们都活得好好的，即使项目会做失败，也没见有倒闭的。所以，程序员真的一点都不重要，随便招几个就行，哪怕写得再烂，项目失败率再高也无所谓？

我臆测，其实往往是这么一回事：项目进展停滞不前，怎么办？那就招一些廉价菜鸟过来做那些比较琐碎的事，比如套个代码模板，写写测试或者写写文档什么的。怎么招？看别的公司是怎么招的，也就挂个职位，等简历么。怎么筛简历？非重点大学的简历直接丢掉，有一门成绩特别差的丢掉，在校有分量的奖拿得太少的不要，……总之，简历上能有任何能和缺点扯上关系的不要，最好是要重点大学相关专业毕业，各门课的成绩都比较好，拿过各种奖，工作积极主动，肯吃苦，肯钻研，执行能力强，有责任心，有较强的抗压能力，活泼开朗，性格外向，有良好的沟通能力，有团队合作精神，能快速融入团队。那面试问什么问题呢？就考一些基础题吧。就考某个算法复杂度在某个范围以内的递归用C语言怎么写吧。再不行就考Singleton怎么实现吧。还答不出来就考考运算符优先级吧。这样内容太少了，再考考什么几个SQL语句加点计算机组成原理吧。算法复杂度是对的，但不是递归，这人连题都不会看，刷掉。重点大学相关专业毕业，连个递归都写不对，刷掉。虽然写的是对的，但连C语言都不会，刷掉。Singleton怎么简单的单词都拼错了，刷掉。运算符优先级就这么几条都记不住，刷掉。虽然我题目写得有歧义，但是动动脑子就知道不会考这么难的，凡是写出两种答案的，刷掉。虽然组成原理这部分，回答看上去挺对的，但好像和我当年学的不一样啊，肯定没上课好好学，刷掉。

最后他们居然在deadline之前几天，把程序整个跑起来了，虽然随时可能crash，但是就这么交差了。

招聘整个过程看上去就是尽快找到候选人的缺点刷掉，而不是试图去找一个有他们需要能力的人，明明是想拖得不能再拖了，却还要只挑他们认为基础好的，而不是选几个现在就能上手干活的。其实这也可以理解，他们一开始想的就是招一些人来做他们不愿意自己去做的事。他们也不愿意去关心，他们的筛选手段是不是显然比随机挑一半丢掉更有效。

所以，我觉得，真的还是不要写程序比较好。可是，一想也不对，万一哪天自己要用了咋办，还不得被这群人坑一遍啊...

我也是要毕业的本科生，还从没有应聘过任何一个公司。看来我也得先把算法基本的东西都背一遍了，免得被秒掉。什么《编程珠玑》《编程之美》里边的小例子都自己实现一边去。。。

大概是每个公司都有不同的文化，你不被微软喜欢，并不见得你就不被谷歌喜欢，重要的是找到适合自己的公司，到底是面向对象重要还是面向算法重要，还需要看这些不同种类的公司不同时间段以后哪个公司在市场上活得更好才对。

@dreampuf 可是我觉得绝大部分都那样啊，而且他们也不会轻易倒闭的。

@lts9165 重不重要我不是确定，我只能说好用

@bhuztez

@akann

可工作还是得找。。。前辈能给点建议么

... 感觉好可怕... 算法不扎实的路过...

工作快 3 个月了我没面试过直接就内推进了 ... 以后出来了怎么办啊嘤嘤嘤！

前一阵子 ex 还嘲笑我说肯定是 SA ... 怎么会去做 Dev ...

=，= 前端面试过 全是算法的！！！全是算法！！！

不知道楼主面的哪个公司，至少互联网公司一般都是重算法不重面向对象。
设计模式对于大数据所要求的高性能没有太大帮助。
传统的软件行业和软件外包可能对设计模式比较重视一些。

我面试过的公司大多两种，要么死命考算法，各种递归，排序；要么死命考数据库，各种统计，偏门得不行的SQL语句优化。

招聘一般是需要什么样的岗位招什么样的人吧？
连正儿八经的工作经验都没多少的，别人可能让你去主导分析设计？
经验这东西都是工作中遇到案例积累的吧？书上看到的东西只能拿来验证经验，别太当真。

@wog 如果你的目的是找工作，很多公司的目的是找个员工尽快把工作做出来，可能一个能熟记各种算法的人是一个理想目标，但是现实并不妨碍你应该有一个自己的理想啊，如果你自己有自己的想法，也可以利用空闲时间钻研一些其他的东西，至于是否真能找到适合自己的公司，那还真是一个缘分问题。

@wog 补充一点，游戏类公司可能比互联网公司更注重设计模式，设计模式书中就有很多这类例子，不知道这里是否有在游戏公司工作的人介绍一些这方面的情况。

@bhuztez 有他们的存在世界才会更美好不是么，就那货撑死了就一垫脚石，所以甭纠结是否非要他们倒掉咯。

其实设计模式在框架和工具包或者系统软件中用得很多，但国内做这类软件的很少，也可能导致国内用设计模式的方法做软件的比较少。

我觉得这个帖子的中心思想是：凭什么不考我特地准备过的内容

楼上正解

如果作为程序员，肯定算法和语言的基础知识更重要，如果作为架构设计师，面向对象设计更重要。

以前参加NOIP的时候背过算法，现在一样什么都不记得了，不过思路还是有的。
学习算法只是对编程的一种启蒙方式，拿它的面试还要求强记真的是有点过了。
而且真的要用的时候，使用现成的库是最安全的做法。
因为有时自己实现的版本还会出各种问题，经不起考验。
就像《编程玑珠》里面说的，90%的人写不出正确的二分查找：

“我在贝尔实验室和IBM的时候都出过这道考题。那些专业的程序员有几个小时的时间，可以用他们选择的语言把上面的描述写出来；写出高级伪代码也可以。考试结束后，差不多所有程序员都认为自己写出了正确的程序。于是，我们花了半个钟头来看他们编写的代码经过测试用例验证的结果。几次课，一百多人的结果相差无几：90%的程序员写的程序中有bug（我并不认为没有bug的代码就正确）。

我很惊讶：在足够的时间内，只有大约10%的专业程序员可以把这个小程序写对。但写不对这个小程序的还不止这些人：高德纳在《计算机程序设计的艺术 第3卷排序和查找》第6.2.1节的"历史与参考文献"部分指出，虽然早在1946年就有人将二分查找的方法公诸于世，但直到1962年才有人写出没有bug的二分查找程序。”

乔恩本特利，《编程珠玑（第1版）》第35-36页

招人大多数原则都是： 只要最合适的。
当然，也不排除那些根本不懂面试或者根本就是为了交差的人阴差阳错的当上了面试官。

总之一切皆有可能啦。一家不行就下一家。

@chloerei 我很好奇你现在做什么？自己创业吗？

@dreampuf 真的更美好么？

算法对于那些人来说，只是用来在面试刷人的工具。至于为什么非要考算法是怎么实现的，这样刷人是不是显然比随机丢掉一部分简历更有效，他们并不关心。反正别的公司也是这么出面试题的，据说这样能反映出基础好不好。他们根本就不关心，你是否知道这个算法哪里能用，哪里不能用。当然，这样很正常，除了面试，算法就和他们一点关系都没有了。

他们喜欢在Apache配置文件里放上上百条重写规则，代码在部署的机器上直接svn co出来，静态文件就放在代码目录里，一不小心，SVN仓库就被公开了。你去wooyun里搜一下SVN，看看那些经常出现SVN泄漏的公司的名字就知道了，他们不仅没有倒掉的，而且还活得很好，收入还会在未来进一步增长。如果他们真的算法基础好，不会连这一点复杂度都搞不清楚吧。明明可以在Apache那里只处理静态文件和简单的反向代理，在应用里自己处理重写规则，并按目录分层的，非要把所有东西都放在一起，明明是O(m+n)的非要搞成O(mn)，弄得配置修改起来特别容易出错。如果哪天事情紧急要改配置，你没考虑到其他重写规则的存在，把配置给搞错了，那就是你没有责任心，没有团队精神，工作不主动或者抗压能力差。这样的人做出来的网络服务你真的敢用么？而且，就算你不用，你身边还是肯定有很多人在用的，你不用你就是异类，而且你也找不到有什么办法能避免这种情况再次发生。你真觉得这样就更美好了么？

他们非要把一个bug很多，API文档不全的开源项目拿来当黑盒用，自己调API在外面包一层，而API文档不全，非要几百个API，一个个自己去猜到底有哪些参数。可是他们说起来编译原理都学的很好的，写解释器甚至编译器都不成问题的，却不愿意花几个小时，看一下代码，理解一下API调用的逻辑，写个脚本把参数都提取出来，而非要让O(1)变成O(n)。几年之后他们就是参与过BigName公司Buzzword项目，有多年大型网站架构经验，海量数据处理经验，大型Scrum敏捷软件项目(管理)经验。可是，猎头就喜欢这样的简历。猎头喜欢看上去能解决困难的问题，复杂的问题的人，不喜欢把大问题分解成几个小的简单的问题，并只能解决简单问题的人。

这就是一个恶性循环。因为随着项目进行，很快就有各种琐碎的事会冒出来，到了某个时间，虽然所有人都在加班，项目进展还是停滞不前。于是，他们就会去招人来解决这些琐碎的事。也就是因为这样，招了很多人之后，功能上尽管有这样或者那样的问题，但往往都能在预期时间内跑起来。所有新版本的代码，都不敢在白天上线，非要到半夜没人访问的时候才敢上线。这也就是为啥要你肯吃苦，有执行力，有责任心，较强的抗压能力。可想而知，这些人招人会出什么面试题了。而且，有一个副作用是，越烂的公司招的人越多，也就是说，你大多数时候能看到的职位都是垃圾职位，靠谱的公司很少招人。可是没有人天生就是一个靠谱的程序员，可是如果你不能靠自己过了这个槛，你就很难进入靠谱的公司，而且往往只能去垃圾公司当苦力，不仅正常工作时间内学不到任何东西，还要不停加班。你真觉得这样很美好么？

如果经常招人却还是项目经常会进展不顺利，高层就很可能会觉得是管理出了问题，去求助于管理咨询公司。找来的公司，只是为了兜售他们的方案，那很可能，第一时间，就要上绩效管理，制定KPI了。但是，开发很难定KPI，很容易就搞成按工作量和是否能及时完成来定了。你一定不能尝试改进自己工作方式，这样才能保证你有足够的工作量，你计划里一定不要有任何实质性开发工作，这样你才更有可能及时完成工作。你工作方式更烂，招来的人更多，你反而更有可能在职位上晋升了。绩效管理最多就只能确保已经确定的东西得到执行。再小的功能的开发中都充满了各种不确定因素，计划里既要定完成时间，又要定要有哪些功能，还要确保计划的功能都能如期完成是不现实的，除非你只制定没有任何实质内容的计划。

为什么学Java好找工作，甚至有传言说大学之前以及前三年从来没写过一行程序，自学一个月Java就找到工作了？因为据说Java好招人。他们的思维惯性就是无论什么东西就一定要用Java，即使别的语言在这个场景下比Java合适的多，也硬是要用Java，理由就是万一人手不够了，Java容易招到人，用别的语言就很难了。而如果你去投简历，别的语言再好，只要不写会Java，你就被刷掉了。(有时候，PHP能代替这里的Java)。

我不是说，我去做，我就一定能比他们做得好。我只是说，这一切实在荒唐透了。我不是说我能从中分辨出靠谱的公司，我只是说要有心理准备，大多少业务没有指数增长，却在不停招人的公司都糟透了。就算筛掉不靠谱的又怎样，哪里能找到靠谱的？纠结的不是他们是否倒掉，而是说他们明明早该倒闭了，却还活得好好的，以至于我怀疑开发是一团糟的公司才有可能获得商业上的成功？

我也不喜欢在面试的时候问一些算法之类的无聊问题，但是我也不会看重面向对象分析与设计。
我个人感觉，一个人会的东西不一定是优势，也有可能会成为你进步的累赘。
务实、缜密、灵活、机敏，有个人的坚持，但不固步自封。

再说一句我个人的感受，无论是百度腾讯还是阿里，7层的开发部员工并非在从事是什么真正有“技术性”的工作，无非就是机械的劳动，超过8层的系统代码就是一坨垃圾，但是就是这些支撑了中国网民相当一大部分的网络生活内容。

LZ自己想想，他们到底会如何划分招聘名额吧。

@zlxstar 自己写点小网站服务，兴趣为主，未说得上创业。

@bhuztez 我觉得写的很好，很有感触

@akann 游戏公司一般招也是招注重算法的，因为一般招聘的程序并不会负责设计上的东西...

让我们从另外一个角度来想一下这个问题，对于很多公司来说，他们希望通过面试来选出他们希望能够招募的工程师，但是这个过程本身有大量的限制和缺陷：

一般来说，很多公司会有2-4轮的面试，每个面试官都会有大约30分钟到1小时的面试时间，每个面试官都会通过多个问题做出自己的判断，而最终是否录用，又会根据多个面试官的评价来得出结论，这个过程看起来非常标准，也非常严格，对于很多被面试的人来说，甚至觉得有些繁琐。但是，这2-4轮面试，最多也就是4-5个小时，而招募来的工程师，我们希望他能够工作至少一年，理想情况，是能够呆上三年以上，面试的时间大概相当于工作时间的1/1000

也就是说，对于1M的数据，你希望通过简单的1/1000采样，来判断整个数据的分布，误差很有可能是很大的。

那么，在这有限的时间之内，我们倾向于寻找两种问题来考察面试者
1. 面试官容易给出明确判断Yes/No的。很多相对抽象的问题，面试官，特别是技术面试官很难通过面试给出判断，比如说，这个人是否是个负责的人，这种事情，面试是很难给出结论的。同样的，相对于基本的数据结构，算法和写程序能力，所谓“设计模式”或者设计能力，是一个相对更难考察的问题。对于应届同学犹然，因为相对来说，他们更少有大量的实际工程和设计经验，考察“设计模式”最有可能考察出来的，反而是“背诵能力”，而且相对于“背诵算法实现”，“背诵设计模式”更加容易
2. 和接下来的实际工作相关的。对大部分刚毕业的同学们来说，工作之后的半年之内，都没有机会实际去设计相对较大的模块，而更多地是学会写Production-Quality的code，所以面试直接根据算法来写代码，是一个更加合适方法。

此外，真正重视招人的公司，也倾向于错杀一千，而不是放过一个，所以即使被挂了，也不一定是你能力不强。

而事实上，我个人的观点也是，“设计模式”相比于“算法和数据结构”，“编译器”，“操作系统原理”在智力上的挑战更少，在经验上的挑战更多。而“设计模式”，在软件的设计能力上，只是具体技术上很小的一部分，即使是考察系统架构设计，去考察“设计模式”，也是非常不重要的一部分。

@bhuztez
这番说法好奇怪啊。。。
就好比你指着满园子长满果子的果树说，这太荒唐了，这些树本应该如此这般的种才对，怎么可以那样种，那样种怎么会长果子，这些树甚至都该死掉，怎么会长出果实？
然而事实是，那些果树就好端端的在那里，果子也好端端的在树上长着。

--

一个应届毕业生找工作的时候，写个基本的程序都不行，还满嘴设计模式，总觉得这样的有点不靠谱吧。

当然不排除这样人中会有牛逼的，可毕竟几率太小了。站在企业的角度，招聘一个初级职位时，完全没必要在所有基础不好的人上花大量的时间只为找到一个不太可能出现的牛人，成本太高。

其实这不一定是坏事啦。算法和数据结构是程序员的基本功，别说国内，国外最优秀的IT公司面试也会问你算法，而且只会更难（不会只是让你写个quick sort的啦)。我大二的时候也迷恋OOP，后来也因为算法被鄙视过，当时心里也不平衡呀，但是从我现在的感受来看，研究算法比捣鼓各种设计模式更有意思，对程序员也更有帮助^_^

@svampire 设计模式按软件工程阶段来说确实应该属于详细设计阶段，不应该属于编码阶段（敏捷法例外），一般公司招人都是招程序员，面试算法为主也是正常的。如果要招架构师的话，应该面试就不是以算法为主了。

算法很难突破了，如果能有所突破，那果断不能呆在这个公司；反过来，OO 方法这条路也很难突破，但和 CS 不同的是，工程领域更容易发挥创造，细微的变化更多一些。

但最后可能干久了就发现磊代码、写代码、设计还是有些不同的 ~_~

楼主提到了学长，想必是应届生。校招的HR苦啊，成堆的简历，真要那种有写过靠谱项目，网上还能查到的，整组的人都会传着看。对着90%简历上项目经验为课程设计的应届生来说，谈设计模式没有意义可能大部分人知道有设计模式这个东西，同时这部分人没听说过Proxy模式。

算法学校里都会教，现成的面试题一大堆。而对于冒泡排序面100个，50个人压根不会写的校招，再去谈设计模式，不更是给HR找憋屈么。而那些真正会对某个具体问题、具体技术死抠的招聘，一般都是急着找人填缺的小公司。

@akann 感谢前辈的回复，我想我以后会把设计模式当做自己的基本功，长期积累，用来提升自己的水平，而不是再把它拿来作为技能来说，我觉得他对我的帮助相当大，特别是在阅读和理解别人写的大型开源系统的时候，

@AntiGameZ 非常感谢前辈的回复。
这样的话，那我下次会把我的GitHub地址写进简历，之前确实是我自己太没有经验了，简历都不会写。
不过想想也好，像楼上其他前辈所说的，也许这样的公司并不适合我，或者说我并不适合这样的公司。
因为如果实习并不能让我比在学校学的多的话，我更倾向于在学校里提升自己的能力。
Ps:我是大三的学生，因为我们老师说如果我可以出去实习的话，下学期他可以帮我办所有课程的免听，所以我去应聘了一下。
另外，算法确实不是我的短处，虽然像《算法导论》这样的书我没看完，但两本《编程珠玑》和《编程之美》这样的书我确实看完了，不敢说全部理解，但我还是动手去解决过里面大部分的问题，之前我参加过我们学校的ACM集训，但是后来因为学院的原因（我是软件学院的，我们学校的ACM是计算机学院负责的）没能参加，并不是我想找什么借口，可是，ACM集训的老师确实跟我们说过叫我们不要自己写排序，用Qsort的效率比我们自己写要高得多。

我没想到会得到这么多前辈的建议，真的很感激。谢谢各位前辈

@wog 实习当然很重要，尤其对非名校的学生，前提是，如果能去一家好公司的话，无论是对简历还是工作能力，比在学校待着“应该”会好不少。注意，我说的工作能力，而不是编程能力。编程、工作、竞赛，都是很不相同的东西。

@wog 你的干劲还是值得称赞的，我还是觉得在国内大家都不太重视设计模式的情况下，可能这方面也的确存在短板，国内那么多公司都想做移动操作系统，明知这很重要，但却没有任何办法，说明国内在某些方面是存在短板的，要做一个移动操作系统首先就需要设计框架，这都需要设计模式的，愿你能学有所长，有一天能找到适合你的公司。

其实我想说楼主虽然只是大三，但是看得出技术比这里许多说设计模式不好的人都要牛。
如果楼主想找工作的话，就去背面试宝典。
如果真的想搞技术做点什么出来的话，建议楼主出国读博，别浪费时间在国内的面试游戏上。

这帖子不是说面试咋不问面向对象么。。怎么还跑楼了。。

和招聘没啥关系吧，靠谱公司不会问你面向对象的。。尤其是知道你是大学刚毕业的。

面向对象虽然说不是神，但好歹是10来年总结出来的东西。是方法论。。。但是。。

凡事有但是，新程序员知道这个东西有好处，因为方便和老程序员沟通。。大多数工作了个5年左右的程序员还是习惯用面向对象的思维的。。因为其他的沟通方式太繁琐太累。。说起协同都是我给你一个接口，你自己看注释去。或者怎么怎么用之类的。。。面向对象设计模式核心就是面向变化。万变不离其宗。没什么太神奇的地方。
谁说面向对象就一定是object了。就一定是一堆class了。。nodejs。erlang。c。到处都是面向对象的核心思想。。。
面向对象需要有大量的编码经验和读代码的过程，才知道怎么用，否则就是一个花样活。所以通常靠谱的面试是没人问你什么面向对象的。这个玩意太虚了。这是一种编码思维和工作方法，面试根本面不出来了。。。算法是内功，你背了比没背强，指不定哪天用到。但你花3分钟自己写和人家1分钟背你被刷了。不能怪面试官。面试官可不知道你是自己写的他是用背的。。。面试也是有风险的。。。

招来靠谱的要比招来不靠谱的难得多。。。很庆幸我们老大宁愿不招，也不招不靠谱的

如果你用不到状态，不写GUI，不写游戏，你用面向对象搞毛啊。

不服的来战。

@est 举几个用不到状态的例子

@dreampuf 打印helloworld，算Fibonacci，bogo排序。等等。

@est TIOBE语言榜上前五名除了C不是主要以面向对象为主，其余四个java,Object-c,c++,c#可都是以面向对象为主哦。

@est 但是 @wog 说的那些东西除了他自己说那是面向对象，其实和面向对象也没啥关系啊

@akann

Java - 企业级

obj-c - GUI

c++ - gui/game

C# - gui/web ui/xna

我没说错吧。

@est 哈哈，我同意你的那部分观点，因为我现在还没有找到反驳你的办法，但从你上面那句话我觉得你的意思是面向对象的程序设计方法是小众化的设计方法，而这一点是我不同意的。

@akann OOP不是小众化的设计方法，而是被严重滥用的设计方法。那种纯OOP的smalltalk，才是小众中的小众。而OOP的精华message passing，实现者erlang，更是几乎被视为异端。。。

@est Fibonacci中的递推变量能算作“状态”么？

@est 看来你还是认为虽然OOP虽然很大众，但还是不应该使用，如果真的不使用OOP了之后，那目前OOP实现的这些功能，其他非OOP能胜任吗？这应该是计算机科学应该研究的问题，因为我现在还是搞工程的，我现在看到的是目前大部分编程任务还需要OOP来完成，因此你认为OOP不应该那么重要仍然说服不了我。当你说服大部分工程师使用非OOP方法做软件的时候，我会听你的建议的。

@akann 告诉我，啥是OOP，为啥OOP更适合你的任务？

@bhuztez 那你跟我说下，我说的哪个跟面向对象没关系，除了排序，我只提到了设计模式和linux内核，我是初学者，可能有些概念没弄清，你跟我详细说说呗

@bhuztez 看来你很像一个大学老师。

@akann 我只是不确定你说的OOP是buzzword OOP还是true OOP，如果你认为的OOP是buzzword OOP那你很难回答这两个问题，如果你认为的OOP是true OOP，那么你回答问题的时候至少思路是清楚的。尽管从上下文来看，我更倾向于认为你说的是buzzword OOP :-p

@bhuztez 我不知道你所说的习惯用语OOP和真实的OOP的严格定义是什么，我理解你的真实的OOP的意思可能是smalltalk那种纯OOP，而习惯用语OOP是指普通口头意义上的OOP的话，我的意思确实是指习惯用语OOP,但我不清楚你为什么断定我很难回答你的两个问题。

从你说的话看来，你也是反对用算法来招人的，这一点我是和你有相同看法的。

实际上无论我们是否把这个问题争论得多么清楚，都不能改变我们现在使用的语言的大多数框架都是建立在OOP基础之上的，我的意思是现在的公司确实应该重视如何使用设计模式这类OO设计方法甚于使用各类算法，因为算法记不住是可以翻书查的，但设计模式你如果不下苦功夫去理解，查书都没有办法。

面试官叫我写1-100的加分，用迭代和递归分别写，我表示不会，然后面试官自己写给我看，想想真是幸运:P

@akann 因为当OOP是个buzzword的时候，很多语言分别实现了不同的东西，他们都管那叫OOP。

可以认为，Smalltalk是一系列不同的语言，而不是一种语言。Smalltalk 80那个其实也和true OOP没啥关系。最初的时候，Smalltalk 7?(不知道到底是1还是2或者都是)是受Simula 67和PLANNER启发，设计出来的一种语言(好像也没真正实现过)，主要特性包括Pattern Matching，Message Passing以及类似后来被称作Actor Model的东西。Alan Kay管那叫实现了OO。他们还开发了另外多种Smalltalk。后来公开的Smalltalk 80就是其中的一种Smalltalk，Alan Kay在很长一段时间内都在鼓吹OO，于是很多人都以为公开出来的那个Smalltalk 80就实现了OO，而现在看上去是连Alan Kay自己在很长一段时间内都搞混了(说OO的时候Smalltalk就指最初的那个，说Smalltalk的时候Smalltalk就指Smalltalk 80了)...

Alan Kay一开始对OO的定义并不是很明确，只是在Simula 67的quasiparallel process的基础上进行改良，可以实现一种容易理解的，可以用来描述某些并发逻辑的模型。Simula 67的quasiparallel process按今天的说法就是coroutine啊。Simula 67里还实现了用于在quasiparallel process之间通信的队列什么的，已经有了一个比较简陋的。或者可以这么说，在1967年，gevent就已经被实现过一遍了。至于怎么改良，改良成什么样，只有一个大概的想法，也没搞清楚哪些是可行的，哪些是不可行的，有没有漏掉了什么。(http://propella.sakura.ne.jp/earlyHistoryST/EarlyHistoryST.html)

* Everything is an object
* Objects communicate by sending and receiving messages (in terms of objects)
* Objects have their own memory (in terms of objects)
* Every object is an instance of a class (which must be an object)
* The class holds the shared behavior for its instances (in the form of objects in a program list)
* To eval a program list, control is passed to the first object and the remainder is treated as its message

后来，Carl Hewitt在Simula 67和PLANNER的基础上提出了Actor Model的形式化定义。但是他的定义还引入了Capability，导致要完全实现非常困难，一直都没有比较好的实现，也就没有流行起来。后来他又提出了CSP，提供了几乎和Actor Model里的Capability等价的功能。这也就是后来的Newsqueak，Limbo，Stackless Python，Go，Rust这一系列语言所谓的并发模型。但是这就不能算OO了，OO的侧重点是Actor Model里的消息模型。

现在流行的语言里面，接近真正的OO的，也就只有Erlang了。如果你了解Erlang的模型了，你就不会觉得 @est 的想法有啥好奇怪的了。如果用我的话来不严格的总结一下的话，就是He who is not an Erlang fanboy, does not understand OO。

@bhuztez 因为我是做软件的，我只知道我要做android软件只能用java或者c/c++,当然也可能scala,但我确实只需要java或者c/c++就能做完全的android软件了，即使我不知道什么是真正的OOP,同理我要做ios软件也只需用 object-c或者c/c++,我也只需用c#就能做完全.net程序了，但是如果我只能使用其他非OOP语言比如Lua，cobol,fortran无论如何是做不出ios程序的,我说的OOP方法更适合我的任务就是指这个意思。

但是如果我要做好这些java,object-c,c++程序，就应该懂得设计模式，因为所有这些语言的基础库比如c++的STL,java的jdk等等都是使用了很多的设计模式，你不理解设计模式，能够深入理解这些基础框架吗，进而设计出自己的框架吗？设计模式显然是OOP方法特有的，你能够将设计模式用于其他过程式语言吗？

@akann 补充一下，设计模式是OOP方法特有的，但也可能将设计模式用于C等非OOP类语言，但即使能用于C语言，仍然属于OOP方法。

多用几种语言，基本上就能明白设计模式是怎样的一种东西

-，- python农表示，偶尔日一次java，认识到设计模式干嘛的了。。

ps：感觉面试面算法啥的，就和找工作要看你本科毕业一样（新人）

以后进去可能高中生不到的水平就能干的事。。。门口就得把个关，入场券。。不然凭什么招你呢

@akann 你真觉得COBOL，FORTRAN什么的不算OOP语言？现实是

* BASIC
* COBOL
* CommonLisp
* Fortran
* Forth
* Matlab
* Perl
* PHP
* Prolog
* S/R
* PL/SQL

这些设计目标完全不同的语言都号称支持OOP，或者至少有一种实现号称支持OOP。当他们在说OOP的时候，他们其实指的是不同的东西，有时候是思路上，有时候是实现上。

当你在说OOP的时候，OOP就是那个buzzword，好像一个语言支持OOP就比别的语言高级了一点。你能说清楚什么算是OOP语言？难道你说的过程式语言和你说的OOP语言，真的有显著的区别么？

冒泡排序都不会，还编啥程呀

见过不会炒鸡蛋的厨师么？

@bhuztez 休战，最近拉下不少工作了。

@akann
模式无可避免。只是由于模式的实践性相当强，直接照搬模式不太可取，同一类问题可以有不同的模式来解决问题。比如Java世界常用Dispose Pattern，跑到C++来就有RAII，C#，python又有using/with statement，这些实践性的东西在单一的设计模式的书中都是没有的。


"但即使能用于C语言，仍然属于OOP方法"
模式（Patterns）只是解决问题的方法论。
举个简单例子：thread pool是一种pattern, 用C语言实现一个thread pool, 不见得要OOP。

这里人真多啊

@yegle 总结的很到位

@lch21 参见51楼我的回复，我的算法基础比别人比不上，比你还是绰绰有余的，因为你语文水平不行

= =！ 被问到设计模式一概答不知道不懂

@wog 吐槽面向对象设计和设计模式的 http://coolshell.cn/articles/8745.html 哈哈

算法和数据结构是基础，没有这些技能，谈设计模式和软件架构就是空中楼阁

看需求，算法和数据结构我只是略懂。程序员是工程师，不是数学家或者科学家。

有一种感觉，越是问算法的面试官，实际项目经验越弱，因为真正做过项目的人会拿项目中遇到的问题来提问，而不是书上的XX排序。

因为这些垃圾公司管面试的喜欢学google，但是他们这群sb也不看看自己公司有没有google那种要求。

因为这种能力的建立于大量的实践经验，而且对architect的需要不是很多，有那么几个就够了，而且要求也非常高。数量上需求更多的还是coder吧

@firsthym can't agree more

设计模式以及面向对象坑人无数。这些东西太抽象，没有大量实践经验空懂理论只是纸上谈兵。相比之下，算法和底层机制的考察更加实际一些。

面向对象和设计模式不是一回事吧？
我觉得这些更多是积累而来的经验而不是单纯可以靠看一本什么设计模式的书来获得的能力
而且我认为设计模式给新手带来的误导往往大于实际的效果

@ipconfiger 我正想贴这个链接呢

@bhuztez 你好像搞混了OO和Actor Model，虽然二者真的很像。

OO跟Actor Model解决的问题不同。OO是一种编程范式、软件工程的方法论，通过对数据和操作的封装提高代码复用性。Actor Model是一种计算模型，解决并发和分布式计算问题。

虽然Alan Kay在采访中提到Actor Model近似与OO中最好的那部分精华，可OO不是Actor Model。Smalltalk和OO概念不是为了解决并发而提出的，而是图形界面革命的产物。

@Alex_L 真正的OO和Actor Model不完全是同一个东西，但大致上是一样的

OO提出来的时候，Alan Kay说的是，一个程序就相当于有很多mini computer同时在运行，他们之间通过消息相互通信，就好像以太网里的多台computer相互通信一样。他只是受Simula 67启发，有这么个思路而已。他还没去实现呢，到底怎么实现，还没定论呢。所以，才有了后面一系列Smalltalk语言。Smalltalk不是一种语言，Smalltalk是一系列语言。Smalltalk 72和Smalltalk 76完全是两种语言，虽然他们都叫Smalltalk。

Actor Model是Carl Hewitt把这类想法整理出来写了个形式化的定义，并且加入了capability。

等后来OO变成了buzzword，于是几乎所有人都不得不搞混了。假如你的语言不号称支持OO，连你自己都会觉得低人一等的。这要怪也得怪Alan Kay他们，他们后来公开的Smalltalk 80和OO真是一点关系都没有。

所谓对数据和操作的封装，根本就什么都不是。从Lisp角度看，这只不过是把(method x y)变成了x.method(y)。这种语法糖甚至在很多时候会降低代码复用。本来method可以用于多种类型，你把method和数据搞在一起，你需要在每种类型里重新定义一遍。从Erlang的角度看，这就是一个Poor man's pattern matching，只能匹配类型，Erlang的作者们根本不屑于承认他们实现了OO。你再想想，Design Pattern那本书完整叫啥："Design Patterns: Elements of Reusable Object-Oriented Software"。

http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

图形界面革命是T-Square和Sketchpad。之前也有图形界面，但是真正向大家展示怎么样写一个图形界面能用来辅助完成工作的，就是这两个了。就相当于是1962年的鼠标，和1963年的平板了。Xerox PARC开始了PC革命，Smalltalk确实一种是为了把PC从军方的实验室里的各种GUI玩具带给广大丝们而设计的语言。GUI里，显然有很多并发。比如，你在一个输入框里输入了，就得再另外一个列表里显示出来，比如SpreadSheet，你在一格里填了个数，因为别的格子里有公式，所以它们的值也会变。你再想一想，Emacs里面就是各种Event-driven了，Tcl/Tk也是。node.js只是最近的hype而已。

http://en.wikipedia.org/wiki/T-Square_%28software%29
http://en.wikipedia.org/wiki/Sketchpad


这就是一个著名的anti pattern，想把在一种场景下有效的方法当成golden hammer推广到所有领域的时候。那个buzzword OO可以算是一个，event driven则是另外一个。

http://en.wikipedia.org/wiki/Golden_hammer

Erlang/OTP只不过是模式匹配，消息机制，语言级的抢占式调度，能把处理并发所需要的各种不同逻辑有效的组合起来解决问题。这就是真正实现了OO。根本达不到什么编程范式、软件工程的方法论这么的高度。

考算法是没有问题的，问题在于直接考算法的背诵有很大问题。哪有直接考默写快排的，这样的题目根本没有区分度。
说白了还是要寻找有解决实际问题的能力的人，默写个快排就有能力了么

@bhuztez

“OO提出来的时候...并且加入了capability。”
这些都没问题，我们的理解一致。

你批评OO的封装降低代码复用：“本来method可以用于多种类型，你把method和数据搞在一起，你需要在每种类型里重新定义一遍。”
我不是太理解这句话的意思，能举个栗子讲一下吗？我的理解是像迭代器这种东西可以用于多种类型，也不需要在每种类型里重定义啊。如果一个method能用于多种类型，必然能通过组合、继承等手段抽象出来；如果一个method需要在多种类型里定义，必然不能适用于多种类型，不关OO事。OO是把需要跟数据封装在一起的操作进行封装，没必要的还跟数据绑在一起就是有病了。

“GUI里，显然有很多并发。比如，你在一个输入框里输入了，就得再另外一个列表里显示出来，比如SpreadSheet，你在一格里填了个数，因为别的格子里有公式，所以它们的值也会变。”
输入框这个例子并发有什么关系？GUI里并发多在哪里？

“Erlang/OTP只不过是模式匹配，消息机制，语言级的抢占式调度，能把处理并发所需要的各种不同逻辑有效的组合起来解决问题。这就是真正实现了OO。”
模式匹配什么时候成OO标配了？语言级的抢占式调度跟OO有关系吗？你对"true OO"的理解还是解决并发问题。Alan Kay设计OO的动机：“Though OOP came from many motivations, two were central. The large scale one was to find a better module scheme for complex systems involving hiding of details, and the small scale one was to find a more flexible version of assignment, and then to try to eliminate it altogether.”真的不是并发。OO跟Actor Model的关系是为解决不同问题用到了共同的思想。

编程范式就是人写程序的方式，方法论的潜台词是你不这么干也能出活，真心没到什么高度，至少不是你想的那种高度。

@bhuztez 插句闲聊，你对Erlang的狂热让人印象深刻。

@Alex_L

> OO是把需要跟数据封装在一起的操作进行封装，没必要的还跟数据绑在一起就是有病了。

就是啊，现在大部分号称支持OO的语言就是有病啊，连Integer都要包一堆方法进去啊。再来展示他们高级的boxing/unboxing的技巧。Immutable的量都有方法明显就是病得不轻了啊。

GUI里并发天然多啊。并发是什么？并发就是有很多状态在同时变化，这些状态还相互关联，一个变了，还能引起很多其他状态变化。就类似Alan Kay的那个mini computer metaphor。就刚才说的spreadsheet，每个格子都有一个值，那就是它的当前状态，接着你去改变一个格子值的时候，别的格子如果定义了公式用到了这个格子的值，那也会相应变化，那就是改变了他们的状态，那就是大量并发啊。


> The large scale one was to find a better module scheme for complex systems involving hiding of details

Message Passing就是为了解决这个问题啊。你并不关心另外一个process内部状态是怎么变的，你把他当成一个黑盒，你发个消息过去就好了。那些把各种方法绑到类型里的语言，就是在意淫调用了一下这个方法就是把这个消息发过去了，结果另外一个object挂了，抛了个错，你也得跟着挂了，这也算封装？只有实现真正的消息机制，才算是封装。消息机制的原型就是Simula 67。OO和传统的过程式语言在概念上有啥区别，过程式语言只有一个过程在顺序执行，OO是有多个过程同时或者交替在执行。

> the small scale one was to find a more flexible version of assignment

Pattern Matching就是为了解决这个问题啊。你是希望写

{ok, Result} = do_something()

还是

errno, result = do_something()
if errno:
raise MyException

还是

try:
result = do_something()
except SomeUnexpectedError:
raise MyException


如果你去翻翻各种邮件列表，肯定会发现Alan Kay提到过最早的那个Smalltalk就是Pattern Matching + Message Passing。

最后，不得不引用一句

Erlang is Smalltalk as Alan Kay wanted it
- Niall Dalton